Screen Flows, Record-Triggered Flows, and Schedule-Triggered Flows are the everyday workhorses of automation. On the surface, these flow types are easy to tell apart, so they seem pretty simple to get started with.
But like anything in Flow, the challenges and pitfalls usually show up once you’re actually building or when they face your users – not because the flow type itself is tricky, but because of the design decisions you make along the way.
Instead of re-explaining what these flows are, we’re getting “in the trenches” with tips and small design choices that can save you a lot of headaches later.
Screen Flows
Screen Flows are the most visible kind of flow, because what sets them apart is the Screen element. It’s their defining feature, and your users will interact with it directly by clicking through, filling out fields, and (hopefully) completing what you’ve asked them to do. Everything seems easy enough… until someone gets frustrated with the design.
One common mistake early on is thinking that more screens equate to more clarity. After all, in design, we’re often told that a clean and uncluttered interface is the best way to hold someone’s attention. This mindset can sometimes make it tempting to break a form into several smaller screens with only a few fields each. But in reality, fewer screens usually mean a smoother experience. If you’ve ever abandoned a form halfway through because it felt endless, you’ll know why this has bearing.
A couple of things to keep in mind:
Keep it light. Strive for balance by not cluttering your screen, but at the same time, don’t split one form into too many screens either. It helps to use conditional visibility to only show fields when needed, or reactivity for even more granular control on how you want the fields on your screen to behave, depending on a number of factors.
Also, plan for abandonment. Even with a well-designed screen, you can’t count on 100% completion every time. What happens if a user closes the tab halfway? It would be nice to offer your users the ability to know where they are in a process using progress indicators on your screen, or add the ability to Pause.
Placement is everything, because a well-designed flow won’t get used if it’s hidden away anyway. Think about context, like should it live on a record page, a home page, or be triggered by a button? Where would a user experience screen ease your users’ effort? Put it where they naturally need it!
The key takeaway here is to build with the user in mind. Put yourself in their shoes and think:
- When filling out the form, what would you want to see first? Put those fields at the top.
- What information would frustrate you if it were missing from the record later? Make those required.
- Beyond the individual record, what will the business need for reporting and KPIs? Be sure the fields critical for measurement and analysis are captured reliably.
- What details are only sometimes relevant? Hide them until needed with conditional visibility.
- What components could help make the screen more efficient and user-friendly?
- If something goes wrong, what kind of error message would help you understand what’s going on?
Record-Triggered Flows
Record-Triggered Flows do their job quietly in the background, which I believe has the potential to be both a strength and a danger. The number one trap I fell into early on (similar to when I was starting with Workflow Rules and Process Builder as well) is setting them to run simply “every time a record is updated”, without realizing that meant every change, even if it was something trivial.
That’s a recipe for unexpected results because this means that regardless of the change, your automation is triggered, whatever small thing is being done to the record. You could be running automation on something completely unrelated every single time the Case status is updated! Yikes.
So the key here is to be specific with entry criteria. This applies to flows in general, but it’s especially critical for record-triggered ones. Don’t just say “when a record is updated”, evaluate whether:
A flow that updates a record, which then triggers itself again, can spiral out fast. Guard against infinite loops! For instance, you might be creating a record-triggered flow on Opportunities that runs whenever there is any update to it, like Stage changes, for example. Inside the flow, you set it to update a custom “Stage Comments” field. But because the flow is also updating the Opportunity record itself, that update triggers the same flow again.
Without conditions in place, you’ve just created a feedback loop where the Opportunity keeps retriggering its own automation.
You can prevent situations like this by using ISCHANGED() as a condition to check whether specific fields have been updated, or by setting proper entry conditions.
Watch out for conflicts. This is crucial, especially in multi-admin and more complex enterprise orgs, because the automation you’re building may not be the only one that touches that object. Two flows, both updating the same field, can cause some very confusing outcomes, and this is also why it’s important to fill out those descriptions!
This falls into general flow best practices on keeping naming conventions and documentation, but it does help a lot in this regard. For more insights on what to keep in mind when creating Record-Triggered flows, check out this article on structuring your RT flow strategy.
And lastly, know the difference between Before-Save and After-Save flows, because this is one of the very first things you need to define when starting to build your flow.
Schedule-Triggered Flows
On paper, Schedule-Triggered Flows sound amazing. After all, their main purpose is to take routine tasks off your plate – fewer things to worry about! In practice, though, they’re trickier than they seem. The biggest catch is volume, because it’s easy to underestimate how many records your flow might pick up once it actually runs. For example, running an automation daily might seem harmless until you realize your broad criteria caused hundreds or thousands of updates overnight.
As best practice, it’s better to narrow things down right at the entry criteria of the scheduled flow, rather than starting broad and relying on a Get Records element inside the flow to filter things later. I see this as similar to using a Data element inside of a loop – think of your flow executing that Get Records element for every instance a record passes your broad entry criteria. It ends up fetching records again and again, which can hurt performance and even risk hitting limits. Your entry conditions act perfectly as your built-in “get”, so that way, Salesforce only collects what you actually need from the start.
The key here is to be intentional. It can make all the difference! One example is to use some sort of control field, like a checkbox or date stamp, to mark “already processed” records. Without this, you risk reprocessing the same records again and again, which can hammer your system and confuse your users. For instance, imagine you build a schedule-triggered flow to send reminder emails for Opportunities that haven’t been updated in 30 days. If you don’t mark those Opportunities as “reminder sent”, the flow will grab the same records every time it runs, and that can result in your sales team getting the exact same email every morning!
I used this same idea in this step-by-step guide to creating a schedule-triggered flow, where the flow deactivates users who haven’t logged in for 60 days. Notice that in one of the decision outcomes, the flow updates a checkbox to flag that a warning email was already sent to the user.
Also, don’t overschedule just because you can! Nightly runs may seem necessary depending on the use case, but think about the real purpose of your automation first, as many processes are fine on a weekly or even monthly cadence.
Finally, mind the time zone, especially for businesses that have users from different regions. Salesforce runs schedule-triggered flows in your org’s default time zone. If your users are spread across regions, that 2 AM run might actually hit during someone’s peak working hours (or be affected during DST shifts), and nothing’s worse than records shifting under people mid-task.
Schedule-triggered flows are powerful, but they’re also easy to forget about… until something breaks! Just like a sprinkler system, they’re great when they turn on as planned, but can be a real mess if you don’t check where the water was going first.
Final Thoughts
These three flow types may feel basic, but they’re also the foundation of so much Salesforce automation. Anyone can add elements onto a canvas, but what makes you a strong builder is learning the little habits that prevent problems before they start.
Being intentional while building is always the way to go, and with more practice, it starts to build muscle memory. Mastering these habits now will pay off big when you move on to more complex flows later on.
