We’ve reached a new era for designing and building automations on Salesforce. A few years ago, Einstein gave admins AI-powered recommendations. Flow then quickly became smarter with every release. There’s new feature after new feature, and now even Einstein for Flow. Agentforce entered the picture in 2024, giving admins the ability to whip up agents declaratively. We also have Agent Script – a way to make AI agents more reliable with set guardrails.
With all of this AI suggesting logic that would have taken hours to build manually (thanks, Agentforce Vibes), building is faster than ever. BUT fast is not the same as good. While it’s tempting just to click “Accept” on whatever AI suggests, the conversation has shifted, and the power now lies with admins who can think architecturally and strategically about what they’re building.
Developers have been wrestling with this challenge for decades. They’ve developed hard-won and experience-earned principles for writing code that’s both maintainable and scalable. And while admins don’t necessarily need to learn to code, they can find benefits in adopting the mindsets that make great developers great. “What are those mindsets?”, you might ask. We’ll dive into them in this article.
Mindset 1: Think in Reusable Building Blocks
Code takes time to build from the ground up, so when developers produce something that works, they maximize its use by building inheritance, utility classes, and shared libraries. When the code does one thing well, it would be great if it could be called from anywhere so that when a new project needs similar functionality, they can reach for the existing building block instead of starting from scratch.
The DRY (Don’t Repeat Yourself) principle states that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In simpler terms, it aims to reduce duplication. It suggests that if you find the need to write the same code lines more than once, just write them in a function and simply call it every time you need it.
This enhances maintainability because if you need to make changes to said code later on, you’ll just have to change that one function, and the change translates to every other place that calls it. Experienced developers do not write the same logic twice.
For admins, this mindset can be applied to many features, but a good example is using subflows for reusable logic. A subflow is a self-contained flow that performs a specific task and can be called from other flows. Most admins know of the subflow’s existence, but few use them to their advantage. Use them the way devs stick to the DRY principle – as the default.
Start with this mental shift. Before you build any automation or flow, ask yourself if it contains logic you’ll ever need again. If the answer is yes (or even maybe), build that part as a subflow from the start. A common reusable block in flows is fault paths.
Mindset 2: Design for Maintainability
Even developers sometimes miss this, but a good rule of thumb is that well-written code should still be easy to understand six months later. Ideally, it should even be readable by another developer who didn’t write it.
The key is clarity – using variable names that make sense, comments that explain what the code does, documentation that captures the intent behind the solution, etc.
The same idea applies to declarative tools like Flow. Clear names, thoughtful descriptions, and standardized naming conventions make your automation far easier to maintain over time because the next admin (or even your future self) would be able to understand everything that goes into that automation.
While developers rely on //codecomments and external documentation to explain their logic, Salesforce admins already have these capabilities right at their fingertips – almost everything in Salesforce comes with a Description field! This is especially true for Flow as well. The flow itself has a description field, and so do its elements, variables, and resources.
I know it can sometimes feel annoying to stop and fill these in when you’re “in the zone” and building quickly, as you don’t want to disrupt your flow (pun intended). But over time, it becomes a habit worth developing. One way to make this easier is to include descriptions directly in the specifications or design notes you’re working from, so that documenting the purpose of each component becomes part of the planning process rather than an afterthought.
Personally, I try to explain what a component does in its description as if the reader is a complete beginner, because after a few months, I often find that I’m that beginner again.
Also, in a team environment (or increasingly, in one where AI tools are starting to help generate or modify automation), this kind of documentation is even more crucial.
Mindset 3: Break It Up!
As people, we tend to find ourselves more efficient or productive when we juggle multiple things at once. I personally do multitasking too, though I can’t say I’m particularly great at it!
It’s a different story, however, when it comes to Salesforce solutions. When one piece of automation tries to do ten things at once, it becomes harder to understand – and even harder to maintain over time. Troubleshooting issues becomes unnecessarily complicated, and it also brings us back to the first mindset: solutions like this are almost impossible to reuse.
Developers follow the Single Responsibility Principle, which states that a class, module, or function should have one, and only one, reason to change, meaning it should focus on a single task or responsibility.
In simpler terms, if a class has multiple jobs, then it has multiple responsibilities and multiple reasons to change. The Flow equivalent of a mega-class is the mega-flow.
A common example is a large “customer onboarding” flow that tries to do everything at once: send emails, create tasks, update the account, notify the manager, assign approvers, update opportunity fields, and maybe even kick off a follow-up case. Before you know it, you’re looking at a 45-element automation that branches in seven different directions and is almost impossible to understand, especially if there are no descriptions anywhere (cue mindset #2). Break it up!
However, keep in mind that this principle is only meant to guide your mindset towards not dumping it all in one place. There’s an important nuance to the Single Responsibility Principle that’s often misunderstood. It doesn’t literally mean “one method per class” or “one action per flow”, but rather separation of concerns.
This encourages grouping together logic that changes for the same reason, while separating logic that changes for different reasons. It does not mean a class should only have one method, but rather that all methods should work together toward a single, cohesive purpose.
In practice, a flow can be broken down in several ways depending on what it does, what it aims to accomplish, and which processes are involved. Tim Combridge explores this idea in his article on flow organization, outlining two different approaches that teams commonly use when deciding how to structure their automations – both of which are worth exploring.
And now, with Flow Orchestration becoming available without the previous paywall, coordinating multiple flows has become much easier. You can orchestrate them to run in sequence as part of a larger process that can involve multiple people as well.
Mindset 4: Architectural Thinking First
Experienced devs don’t just open VS Code and start typing when they get a new requirement. They need to see the bigger picture first, to answer questions like: What are the inputs and outputs? Where will this connect to other systems? What other parts of the process will it touch? And is there anything in it that may need to change 6 months from now?
The planning phase isn’t glamorous, but it often takes just as long as the building phase. When you think about it, the main advantage is avoiding the consequences of poor design later on. Time spent thinking things through upfront is dramatically cheaper than fixing problems after the fact.
Another software development principle that often guides this thinking is KISS: Keep It Simple, Stupid (or as I like to say instead, Keep It Super Simple). It’s a reminder that solutions don’t need to be overly clever or complex to be effective. In fact, the simplest solution that solves the problem is usually the best one, and ironically, arriving at that simplicity often requires stepping back first.
When you understand the broader architecture and how everything fits together, it becomes easier to spot the cleanest path forward.
For admins, this mindset applies far beyond Flow and automation. Before fulfilling any build request, pause and think about the bigger picture. How does this change affect adjacent functionality?
It helps to open a whiteboard (it can be physical or digital) and map out the logic. Identify decision points and ask where reusable components might exist (actually bringing us back to mindset #1). Think through the extremes and edge cases as well.
Some out-of-the-box Salesforce features that can help you with mapping out dependencies and architecture are the Schema Builder for the general view of what your data model looks like. Also, Flow Trigger Explorer is useful for visualizing and managing the execution order of record-triggered flows. Other smaller but helpful ones are the Field Dependencies and the “Where is this Used?” button in Object Manager.
Mindset 5: Expect Failure
Nobody’s perfect – we say this all the time, and yet we strive for perfection. The statement is very true, though, and it’s a mindset that actually gets you better prepared for failure. In professional software development, a method without error handling isn’t even finished. It’s merely a draft!
When I was doing my beginner classes in Apex, test classes were some of the things we learned last, but I quickly realized how they can sometimes take as long as the actual code to build. This is because they’re equally important – and during the testing phase, that’s exactly what you’re looking for: failure.
Experienced developers always keep these failures in mind, and so they aim to design their systems to degrade gracefully when something goes wrong. There is no initial assumption that the code works, but the key thought is that “when this breaks, what happens next?”.
It’s important that admins know that fault paths exist for a reason! A good fault path does three things:
- Captures what went wrong.
- Notifies someone who can fix it.
- Ensures the failure doesn’t mess with your data.
My colleague Andreea Doroftei wrote this article on how to set up a reusable fault path in Flow, which I’m sure will easily become an important part of your building block library. It actually combines this mindset with mindset #1 on thinking in reusable building blocks.
Also, if you want to look at more error happenings, you can navigate to Setup → Paused and Failed Flow Interviews. This guide on solving flow errors is a great place to start.
Bonus Mindset: Test Everything (Especially What You Didn’t Write)
Good developers don’t ship untested code! And while testing has always been a default practice in software development, it isn’t really always talked about in admin work.
Salesforce knows this, and that is also the reason why the testing and debugging features in Flow Builder have been getting constant improvements in these past few releases. For example, you can run automated tests for record-triggered flows and autolaunched flows, helping make sure that logic behaves as expected when specific conditions and inputs are provided.
Screen flows can now also be debugged directly in Flow Builder, and while this feature is incredibly useful, screen flows rely heavily on user interaction. This means it may also be beneficial to do manual walkthrough testing to ensure the experience behaves as expected. Automations still benefit from structured manual testing, where you walk through different scenarios the way a real user would. Just make sure you aren’t doing things directly in production!
This is more prevalent now that we operate in an AI-assisted world. Salesforce has been pushing AI and Agentforce so much that it’s even started to shift the roles of admins and devs a bit.
AI-first Salesforce makes testing non-negotiable. When you build something yourself, you at least understand the logic you’re testing. When AI builds something, or if AI assisted your build in any way, you’re testing logic that may have assumptions you don’t know about. You may have used vibe coding, Einstein for Flow, or simply asked ChatGPT a question while building.
Either way, test every branch. Test the fault paths. Test with records that shouldn’t trigger the flow to make sure they actually don’t! Test with unexpected data like null fields, duplicate records, and unusually long strings. If something surprises you in testing, it’s an opportunity to deal with it and not let it surprise others in production.
Final Thoughts
The programming principles I’ve mentioned in this article, like DRY, Single Responsibility, and KISS are not meant to be strict or rigid rules that must be followed in every situation. Actually, taking them too literally can be just as harmful as ignoring them altogether. Good developers (and good admins) understand that these principles are only guides for better decision-making. There will always be trade-offs, and your best judgment is the real skill that sets us humans apart from AI.
If this article helps you pause before your next build, asking questions like “Is this reusable?”, “Will this be understandable six months from now?”, or “What happens when this fails?”, then you’re already adopting the kinds of mindsets that have helped devs design reliable systems for decades. And those mindsets will serve admins just as well.
