5 Basic Principles to Creating Stable Process Automations in Salesforce
10 min
Look, I get it. It's the last week in Q2, and you need to boost productivity to hit your goals… so you add a couple of automations using Process Builder, maybe even a Workflow Rule. They're quick to implement, and you get the almost immediate satisfaction of removing a mundane or redundant task forever! So… you grip your mouse and ten clickity-clacks of the keyboard later, you activate your new time-saving process definition, and you're off to the races!
Wait… did Cheryl from accounting just shout your name angrily, followed by a stream of expletives that would make a sailor blush?
Oh no! now Bob from Sales is punching the wall, and did someone just kick a Ficus across the lobby? NOT THE FICUS!! You LOVED that plastic tree!
You sit there in disbelief as you watch your team devolve into what can only be described as a 'Harlem Shake' video without the catchy bass drop. What the heck is going on out there?
… ah FU-U-U-U-D-G-E. In all that excitement, you missed the stream of FlowApplication Error emails that have been spamming you for the last 7 minutes. You saw something out of the corner of your eye just now, and without even doing a double-take, you know what it says. You can tell by the way your heart immediately sunk into your stomach as your brain put it all together…
Error element myRule_1_A1 (FlowRecordUpdate).
The flow tried to update these records: null. This error occurred: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: ProductCodeTrigger: System.LimitException: Too many SOQL queries: 101. You can look up ExceptionCode values in the SOAP API Developer Guide.
Only, you didn't say "Fudge." You said THE word, the big one, the queen-mother of dirty words, the "F-dash-dash-dash" word!
It's ok!
We're gonna get through this together, Ralphie! Before you roll back everything and try again, let's take a quick look at these 5 Basic Principles to Create Optimized Process Automations that can help you refactor a troublesome environment AND stay in top shape for years!
1. Should I Stay or Should I Flow?
Any time someone asks you for an automation, your first question should be "Why." There are hundreds of thousands of quick and straightforward automation possibilities you could build, but even the smallest pebble can add ripples to an otherwise calm lake. Make sure that what you're adding is worth the cost if it ends up creating some waves!
One of the scenarios I see a lot are the 'our old system did it this way' requests. End users will often have a favorite feature or layout on their old UI that doesn't match how Salesforce does it. Understandably, and as Admins and Developers, our job is to do our best to accommodate any requests if it makes the client happy… usually. Sometimes, it's in the users' best interest for you to say 'no' and explain why their request is potentially problematic.
Take, for example, the Contact and opportunity objects. Perhaps the user wants to make edits on the Opportunity and have them sync back into the contact. Oh, and they also require all changes on the contact record to sync over to the Opportunity record and the Opportunity record to stay in sync with (and Update) the Account record. Can it be done? Of course. Should it be done? NO! IT'S A TERRIBLE IDEA!!! Not only would you risk running into recursive update scenarios that could tie up access and kill org performance but maintaining that into the future is going to be an unstable nightmare in 2-3 years after a handful of new apps are added into the mix.
Change sucks. Most of us hate it, but eventually, we realize that it's for the best! If you keep these things in mind and learn to strategically 'Stay' with what you have instead of 'going with the Flow' its sometimes easier, faster, and better for org stability to train people on the 'new' way vs. converting a shiny new diamond-of-an-org back into the lump of coal that came before it. If you don't have a choice and you absolutely must add it, keep reading!
2.Don't behave like a New Kid on the Block… use The Right Stuff!
No matter how experienced you are as an Admin, Developer, or User, you will make mistakes. Even the best-laid plans can hit a speed bump or six. It happens.
While it's not within your control to 100% ensure there will never be an error, you can and should be doing everything you can to minimize the risk of occurrence. One way to do that is to understand how different standard systems and processes work together. Just because something is a common feature does not mean it is without flaws or exempt from governor limits. Understanding the right tool for the correct use case can save you much frustration!
Let's look at the four automation types and the scenarios they are best suited for, and a few reasons they are not.
- Workflow Rules
- Best suited for: Sending XML outbound messages to an external endpoint. That's it. Stop using flows (angry face emoji).
- Not well suited for: Anything else. No, seriously, stop using Workflow Rules. Aside from Outbound messages, all Workflow Rules can be implemented more efficiently in the options below. Salesforce has stated they won't be enhanced anymore moving forward either, so it's time to embrace the future!
- Process Builder
- Best suited for: Simple, and I do mean simple, automations. You do not want to have multiple process builder definitions per object, and an extensive, complex Process Builder is expensive in terms of processing and governor limits. Stick to simple single-step automations like sending an email alert or creating a record.
- Not well suited for: Record Updates. For more on this, see #5. *Keeping your Mogwai out of direct sunlight, away from water, and far from any food after midnight; Also worth noting, like workflow rules, Process Builder will no longer be enhanced by Salesforce. It's reached the end of its development life cycle.
- Flows
- Best suited for: Anything you would have used workflows or process builder for; Relatively complex automations; Simple wizards with a visual element; Record updates; and a lot more!
- Not well suited for: Large or complex automations. Complex wizards (especially those with many custom validations); **Critical functionality that would send the system to a grinding halt if broken.
- Apex Trigger
- Best suited for: Record updates; Complex automations; **Consolidating process builder; Basically, anything you can't do with a Flow; Situations where you need to control the Order of Execution very carefully.
- Not well suited for: Automations the require immediate user feedback; Automations that need frequent updates; Automations that would benefit from a visual component to map out the process.
*Oh, you're reading everything? Nice! For real though, keep that Mogwai dry…
**The most significant downside of a complex flow, especially if it's mission-critical, is that they are practically effortless to break and can be challenging to maintain if they involve aspects that need to be updated regularly. If you want a stable, complex, mission-critical automation to be the foundation of your business process, use a Trigger.
***Remember, Process Builder is extremely expensive in terms of impacting SOQL and DML limits. A Process Builder definition with ten automation steps could do 10 SOQL and 10+ DML, whereas you could likely do the same process in a Trigger with 1 SOQL and 2 DML.
3. K.I.S.S.
Keep. It. Simple. Stupid.
Don't over-engineer! After creating or updating any of the methods noted here, do a retrospective review of the entire process. Often, you can combine and simplify your process at some point. Simplification could be moving re-used apex out of a Trigger and into a utility class; Moving Process Builder definitions into a Trigger; Combining SOQL to reduce limit counts; Etc. Etc.
4. Pros before Oh-Noes
When in doubt, consult the pros! Not all heroes wear capes. Perhaps one of your peers has implemented something similar for another org. It never hurts to ask around the office or hop on a few forums to look for advice. You don't always need to reinvent the wheel, sometimes you just need to grab a tire off the rack, add a few counterbalances, and you're off to the races! It's always better to ask for (or at least look for) help from a pro than hang your head in shame, screaming 'Oh no… the system crashed, and my automation was the root cause!'
5. Every Rose has its Thorn
Understanding the system impact of your automations is what separates the pros from the amateurs. If you really want to up your automation game, run some performance tests before and after to see how expensive your automation actually is. It can be a great way to identify bottlenecks that will not scale or even shed light on existing opportunities to optimize your flows!
BONUS ROUND!
Here are a few exercises you can reproduce in your org (via anonymous apex function) to see what's really happening. Don't listen to the Wizard… always pay attention to the man behind the curtain!
I took a simple record update action for these tests: incrementing a number field by one any time another field is changed.
To make the test repeatable and straightforward, I assigned a specific number to each automation type. If the driving field changed to 1, it launched a Workflow Rule; if the number changes to 2, it executes process builder, and so on.
On the second test, I added another field update in the same automation to show how a single field update can significantly impact your governor limits.
I also added an 'Allow Recursion' example in one of the Process Builder tests to show why that checkbox can be very expensive and should never be used without fully understanding its impact.
Here is the code I used to trigger a consistent record update for these tests. The benefit of executing these from an anonymous function vs. the UI is that you can make sure there are no other processes on the UI affecting the outcome. I encourage you to use similar logic in your org to see where you stand!
Insert Test
Update Test
Workflow Rule (Triggered from Apex)
Test 1 Workflow Rule:
Test 2 Workflow Rule:
Test 1 Results:
- 1. Single field incremented on Insert
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|1 DML operations After Execution 🡨
this DML comes from the apex insert for our test, not the workflow! - DEBUG|0 SOQL operations After Execution
- DEBUG|0 SOSL operations After Execution
- Single field incremented on Update
- *Same as test 1
Test 2 Results:
- Two fields incremented on Insert
- *Same as test 1
- Two fields incremented on Update
- *Same as test 1
Flow (Triggered from Apex):
Test 1 Flow:
Test 2 Flow:
Test 1 Results:
- Single field incremented on Insert
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|1 DML operations After Execution 🡨 this DML comes from the apex insert for our test, not the flow!
- DEBUG|0 SOQL operations After Execution
- DEBUG|0 SOSL operations After Execution
- Single field incremented on Update
- *Same as test 1
Test 2 Results:
- 1. Two fields incremented on Insert
- *Same as test 1
- Two fields incremented on Update
- *Same as test 1
Process Builder Flow Definition (Triggered from Apex):
Test 1 Flow Definition:
Test 2 Flow Definition:
Test 1 Results:
- Single field incremented on Insert
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|2 DML operations After Execution 🡨 One of these DML comes from the apex insert for our test; the other is from Process Builder!
- DEBUG|1 SOQL operations After Execution 🡨 This SOQL is from Process Builder!
- DEBUG|0 SOSL operations After Execution
- Single field incremented on Update
- * Same as test 1
Test 2 Results:
- Two fields incremented on Update
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|3 DML operations After Execution 🡨 One of these DML comes from the apex insert for our test; the other two are from Process Builder!
- DEBUG|2 SOQL operations After Execution 🡨 Both of these SOQL are from Process Builder!
- DEBUG|0 SOSL operations After Execution
- Two fields incremented on Insert
- * Same as test 1
Bonus Test Results:
- Two fields incremented on Update PLUS 'allow recursion.'
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|10 DML operations After Execution 🡨 One of these DML comes from the apex insert for our test; the other nine are from Process Builder!
- DEBUG|9 SOQL operations After Execution 🡨 ALL of these SOQL are from Process Builder!
- DEBUG|0 SOSL operations After Execution
Apex Trigger: Before Insert, After Insert (Triggered from Apex):
Test 1 Trigger:
Test 2 Trigger:
Test 1 Results:
- 1. Single field incremented in Before Insert.
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|1 DML operations After Execution 🡨 This DML comes from the apex insert for our test, not the Trigger!
- DEBUG|0 SOQL operations After Execution
- DEBUG|0 SOSL operations After Execution
- Single field incremented in Before Update
- * Same as test 1
- Single field incremented in After Insert, After Update
- *Infinite Recursion -> Governor Limit Errors
Test 2 Results:
- Two fields incremented on Update
- DEBUG|0 DML operations Before Execution
- DEBUG|0 SOQL operations Before Execution
- DEBUG|0 SOSL operations Before Execution
- DEBUG|2 DML operations After Execution 🡨 One of these DML comes from the apex insert for our test; the other is from the Trigger!
- DEBUG|1 SOQL operations After Execution 🡨 this SOQL comes from the apex insert for our test, not the Trigger!
- DEBUG|0 SOSL operations After Execution
- Two fields incremented on Update
- * Same as test 1
