If you’ve been in the Salesforce ecosystem for a while, you probably remember Process Builders and the idea of one Process per object – much like Apex triggers!
One of the nice things about Flow these days is that you can have many Flows per object, and use the Flow Trigger Explorer to set their order of execution, giving us a lot more control over that configuration than was available in the past, which is great!
But just because we can have more than one Flow per Object doesn’t mean we should create a separate flow for everything. As good Admins we want to be conscientious of minimizing our technical debt (more on that later) and streamlining our operations whenever we can.
Decision components and flow connectors make it really easy to combine automation requests into one flow when it makes sense. Records with a stage and business process are a great example of this. Often, a customer wants a record to move through the various stages as criteria are met, and maybe also would like some email alerts, and some internal Salesforce notifications to occur throughout that process.
We definitely could create a Flow to evaluate the criteria to change the stage to one value, another Flow to evaluate the criteria to change the stage to another value, a Flow to do the email alerts, and a Flow to do a custom Salesforce notification – but wow, what a lot of Flows all being triggered by the same criteria!
Instead, why not do one Flow that evaluates the criteria, and makes use of Decisions and Flow Connections to set up your field updates, send your notifications and email alerts all at once?
Sometimes, you really do need just one Flow that does one specific thing, but if you find yourself evaluating new Users to assign different permission sets or different criteria to change the same field on an object in multiple Flows, this is a good opportunity to streamline and combine those Flows into one!
Above: A screenshot of two flows, one titled “User – Assign MRA Permission Set’ to assign a specific permission set to a user, and one titled “User – Assign Permissions”, a generic flow to assign different permission sets based on criteria
As Salesforce admins, we often have an opportunity to be the quiet heroes of our systems, and pay close attention to minimizing our technical debt – it helps us as admins, and it helps other systems that are interacting with our Salesforce org to have clean technical flows whenever we can.
There are many ways within Flows that we can support good technical debt management practices:
- Entry Criteria: This one is critical and the easiest possible one to implement. When you’re creating a Flow, give some good thought to when the Flow entry criteria – if your Flow is only supposed to run when your Opportunity has products, you probably don’t need to run the Flow on create – you can set that to Trigger the Flow When: A record is updated, and set your Entry Conditions to evaluate that it must have a related Product. This stops your system from running through Flows that will never meet the criteria, or trigger it, and allows you to save some unnecessary technical operations!
- Decisions: Decisions and connecting those decisions to components is what gives us the flexibility to use a Flow for more than one requirement at a time. Consider your Decision criteria closely, and make sure you’ve really defined the trigger for an event well, and then make use of connections to continue evaluating your logic. Don’t forget the default behavior for a Flow after a decision path is followed is to end the flow – if you want to evaluate the next decision, you’ll need to connect that component! This helps our Flow run efficiently and correctly, and keeps our tech debt and unnecessary updates low.
- Reusing components: Setting up components takes a lot of time, and can be frustrating to try and repeat if you’re doing the same action more than once. Make use of those flow connections to reuse a component can be a real time saver, and can help you keep your flow clean.
- Call early, call less: Say you’re trying to notify a team when a record meets different criteria, so you have a bunch of decision criteria that are all going to send a notification to the same group. You could certainly create a Get component on each decision path, and use it. But this makes for a lot of duplicated components in your flow, and while it’s not necessarily making a call every time (of course, we only call the component when the decision is evaluated to try), it does make for a hard time for whoever has to work with that Flow down the line. It’s much easier if we know we’re going to reuse a Profile, or Group, or Notification that we call it early in our Flow logic, and reuse that in all our branches.
Above: A screenshot of a flow in canvas with all the elements displayed that makes use of Decisions, and reusing a component
We’ve all been there – you open a flow someone else built (or maybe one you built!) and look at it in despair trying to understand what variable is being set where, what’s using a formula, who’s updating what when and why?
Apex is easier to work with in this respect – it has a set syntax that’s pretty clear! But flows are a little more flexible and that flexibility can cause us trouble down the road. So what can we do as admins to help our future selves?
One person on your team names their flow “Super cool flow #17”. You personally name your flows “Flow – Updates contacts”. It’s good to have a consensus on how you’re going to name flows, and what that means for you. Even if your team is just you and yourself, this is still super helpful for future Team You!
For record triggered flows, I always use “Object Name – Quick Description” like “User – Assign Permission Sets”, and for screen flows, I always use “Screen – Quick Description” like “Screen – Create Contact”.
Sure – you can always add the Trigger column to the Flow Definitions list view, but that’s a column that I could get rid of with the right Flow Name instead. It makes life much easier when you’re trying to quickly find all the Contact flows without clicking into the Flow Explorer, or to quickly sort and filter. It’s also very helpful when you have code involved in your org too, your developers will thank you when they can quickly spot how their code is interacting with a Flow, and which Flow it is.
Once you’ve got your Flows nicely named, it still can be quite overwhelming when you open up that Flow and try to navigate. I adopted a very strongly influenced by apex syntax for myself:
- Components: These start with what type of component it is, then the name of what it’s doing – for example “Get: System Administrator Profile” or “Email: New User Request.” Ideally, we want to keep this brief but descriptive. Sure, when we’re navigating the Canvas the icons are all nice and colorful and descriptive, but when we’re deep down in assigning a variable from a Get component 10 steps up, it might not be visible, and it’s much easier to find when you know exactly what it’ll be named as!
- Variables and Formulas – these are the things that trip me up the most often, especially as they are sometimes virtually interchangeable in terms of values! You’ve got a formula to set the owner, and you’ve got a variable to hold the owner you set, and they’re both named Owner….but you can’t have duplicate resource names, so you’ve done something to distinguish them. In six months, will you remember what you did? Probably not! So make your life easy! Variables always start with “var” and formulas always start with “fx”. So you end up with “varOwnerId” and “fxOwnerId”, and suddenly it’s much easier to keep track of what’s doing what.
As always, you want to find a system that works for you, and your customer or team, and that is maintainable, and scalable for the future as your Salesforce org grows and matures.
These conversations and decisions will help you navigate your system with ease and help your future you or your team all have a better consensus of what’s happening with your automation.
Above: A screenshot of the Resources menu in a flow using a unified naming convention for different elements and resources
Megan Gallagher
Megan is a senior Salesforce consultant at Agency 73 specializing in complex implementations and business processes, maximizing Salesforce value for admins and end users, and leading integrations with third-party platforms.
Contact Megan to start working magic with Salesforce.