5 Common pitfalls to avoid when creating Process Builder automations
10 min
Let me start by saying Process Builder is an excellent tool for declarative automations with minimal effort. Sure, it has a bit of a learning curve, but the potential is endless once you get the hang of it! Need to send out an email when a status changes? No problem! Update several related records based on a field change? You got it!
Like any powerful administrative/declarative tool worth using it’s all in how you use it. There are a few key factors to keep in mind any time you create a new flow in process builder that can help you maintain a scalable automation library for years! Whether you’re just getting started with Process Builder or consider yourself an automation guru here are some best practices you’ll need to master if you want to avoid these common pitfalls that frequently lead to avoidable problems 2-3 years down the road.
Remember, with great power comes great responsibility!
.png)
1. Strive to maintain a single Process Builder flow per object
As I stated above, Process Builder is an awesome and powerful feature that I use and recommend regularly. It’s so useful for creating automations that it can almost become addicting! The unfortunate drawback to this ease-of-use lies within those two words all Salesforce admins and developers love to hate… Governor Limits!
To be more specific, SOQL Query and DML Governor Limits.
What many novice or even intermediate admins don’t realize, is that Process Builder flow definitions can perform multiple SOQL and DML operations every time they execute. Over time as more and more processes are created, they can add up quickly and leave you in a sticky situation.
Good:
Bad:
Take for example a simple process that sends an email message based on a status change for some object. Let’s say when that status changes to ‘Application Requested’ a process executes that creates and sends the email. Once the email is sent, the status of the record which triggered the process is updated to ‘Application Sent’. Now let’s say there is another process that looks for newly sent application emails, and updates some field or object tracking the number of applications sent per week. If we set this up as two separate processes, they will fire independently of each other (and not necessarily in the same order each time). SOQL and DML may be required for both processes, even though they may not both be fully executed, due to the entry criteria being split into multiple processes and being evaluated independently.
Once the email application is requested, criteria 1 is satisfied and the email sent in criteria/step 2. Upon completion of this step, the record is still in context of the process and does not need to be queried again to verify the entry criteria, and if the tracking field/object was on the object which executed the process it could be updated in a single DML.
This is only a high-level example, but the concept should be clear: Avoid redundant actions that execute SOQL or DML operation whenever possible. While it may not always be the case, if you treat every entry criterion as if it were its own SOQL statement you can train yourself to always be concise with your criteria.
The last thing anyone wants is to find out the day of deploying a new feature that it has hit a SOQL limit error and the only way to resolve it is to either refactor the implementation or consolidate new and existing processes to shave off SOQL queries!
2. Don’t get caught up in the ease-of-use
Process Builder can handle a lot of redundant task automations quickly and easily, no question there. Before you go out and automate every email and status transition you can find, however, ask yourself these three questions:
- Is this necessary?
- Is this maintainable?
- Can this be combined into an existing process?
If you answer ‘no’ to #1 or #2
Consider either leaving it off the table in favor of a more beneficial process with greater impact to the company or users. Many things can be automated, but they do not always warrant the effort or added complexity they may introduce into the environment. Twenty simple automations can become just as problematic as one complex automation as a company grows.
If you answer ‘yes’ to #3
Consider adjusting an existing flow/process/trigger to accommodate the new logic while also minimizing any additional SOQL/DML operations. There may be an existing process with the same entry criteria being used for another use case. Instead of creating an entirely new process that would reproduce duplicate steps, combine them!
☝🏽 Remember, the fast and easy solution is not always the correct option. If you’re not considering future usage while adding new features… you may as well start preparing for the inevitable systemic failures that will one day destabilize your org!
3. Combine logic wherever possible to reduce DML
It’s worth mentioning that over time, Admins and Developers alike may unintentionally add new features without fully understanding the existing functionalities. This should obviously be avoided at all costs, but it does happen from time to time. In larger or more complex environments this can become a difficult situation to get out of. Don’t let that happen to you, be proactive!
We’ve all had those days where a 911 production emergency pops up and a rushed patch had to be implemented to keep the business moving. It happens. When you have 5 years of legacy flows and 20 relationships to traverse it can be a daunting task to trace back all those related flows looking for common or shared logic where you can inject your patch with minimal side effects.
Well in case you didn’t already reach this conclusion on your own… this is a trap, and you’re setting it for yourself.
These situations can and do happen even with the best planning. The thing to remember is that it’s not always the quick fix itself, or even the fact that it happened in the first place that you should focus on. Equally and sometimes more important is how you react to the situation and the steps you take to prevent it from happening again.
- When you hit the wall of DML and SOQL exceptions in particular, a proactive strategy can be your best plan for preventative maintenance.
Instead of waiting until the last minute, pop into your active flows or processes occasionally and review how they are structured. Are there redundancies that can be consolidated? Do you have complex flows that have evolved over time and are now better suited for an Apex Trigger?
Questions like these will lead you to discover bottlenecks before they find you!
Business processes evolve as a company matures and will continue to do so long into the future. By combining and simplifying processes proactively you can stay one step ahead of potentially catastrophic bottlenecks and keep your org running like a well-oiled machine for many years.
Leaving existing processes alone for stability is fine, but don’t be afraid to optimize them for preventative maintenance. Sometimes what isn’t broken still needs to be fixed!
4. Keep it Simple, complex logic should be handled in triggers
You are likely already aware that some logical operations can’t be done via Process Builder. Plain and simple, no grey area there. If it can’t be done in a process or flow, an Apex Trigger is the obvious choice.
It can be difficult to decide sometimes between flows, processes, triggers, etc. Sometimes you may not even realize it’s the wrong choice until you’re halfway down the implementation path. There is no one-size-fits-all answer for this. There are always exceptions no matter how many rules you follow.
- When those exceptions do pop up, here a few tips to help you out.
- 💡Consider the limitations of each option against your use case.
This can be an easy first step to rule out at least one choice. - 💡For each option, are they scalable and maintainable?
Think about how you see the company growing in the next 2-5 years. Build your process with that in mind and you will be prepared when it’s time to scale up! - 💡Does the addition of the logic to any existing process or flow over-complicate the flow in a way that it becomes difficult to add more to it in the future?
If the answer is yes, don’t do it! There must be a better way! - 💡Will there be competition of resources if you choose one over the other?
For example, you have flows, workflow rules, and a trigger on contacts. Would adding a process be the right move here? Perhaps after comparing all the existing automations, it would be more easily maintained by converting everything to a single trigger or process. - … and above all, don’t be intimidated by Apex! In the long run it may be better to learn a new skill or hire a developer than forcing a square peg into a round hole!
5. Know your flows! Be aware of other flows, triggers, etc. that are linked to the same object
💡 This tip is short and sweet:
Review all existing automations on an object before you add more! Don’t let yourself get caught in an infinite loop of flows launching triggers launching flows…
💻 Bonus Tip: Know the order of operations!
Lastly and most importantly, know how flows and triggers execute. In an Apex Trigger you have complete control over when the process executes. Before an update, after an insert, etc, etc. For example If you have a trigger that is dependent upon a value from a process, you could easily cause an infinite loop or your data could always be out of sync!
*Side note: if you’re chaining processes and triggers together in that manner you may have larger problems to worry about ;-)
The order of operations is as follows. Remember it and save yourself hours of frustration!
- Before Triggers
- After Triggers
- Workflow Rules.
- If there are field updates in your flows, the record is updated again, which can restart the cycle.
- Lastly, Processes and Flows are executed.
Good luck!
