Salesforce Obscura: Stop! Put That Process Builder Down!
Do you really need to automate that?
You may be a pro at Flows and Process Builders. You may just have discovered the amazing power that comes with Salesforce’s declarative (fancy way to say “no code”) tools. Either way, maybe you are feeling like you can SOLVE. ALL. THE. THINGS!!! for your users!
Yeah, me too. And many other tools before my journey with Salesforce. In the last 25ish years of building automated computery things for fed-up end users, I’ve learned a lot about jumping exuberantly into making my life a whole lot worse with all of my automation powers.
When asked for automations now, I find myself saying “not yet” a lot more. I have a checklist I use now for anything that might incur technical debt or risk, and it’s loosely based off of Bill Gates’ quote about automation and inefficiency.
”The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
- Bill Gates
In most of my work the risk is less about inefficiency and more about lack of clarity. Applying automation to an ad-hoc and ill-defined process will make it more ad-hoc and ill-defined. This, in turn, will lead to fear and superstition and people putting things in fields because that’s just what we’ve always done, garbagifying your data even further.
Once a process is automated and tested, the automation will faithfully execute the rules you set up without any exceptions or judgment a human might place on the same set of data. They are relentless. And once you start automating, it’s super common to automate more in response to edge cases and new behaviors that crop up as a result of your first automation.
A wiser Micky, getting trampled by his relentless automations and wondering if he should sorcel some fire to burn the brooms. Because how could brooms on fire go wrong?
A Simple Checklist that Is Really Hard to Complete
No matter how much you play that clip from Fantasia at your users, they will want automation. In many cases, the automation request is valid and will legitimately save time and reduce error. But in many other cases, you’ll get an army of well-intentioned automated brooms marching around your organization sloshing water everywhere and annoying people.
”…I have observed that people want the magic new thing more than they want improved management to fix problems. Managers need to carefully determine the areas in their business where new technology is the right choice and other areas where a back-to-basics management approach may be more effective.”
- Temple Grandin, quoted in Tribe of Mentors by Timothy Ferris
To avoid automating your way into misery, see if you and your users can answer the following questions:
1. Can I speak to the manager (of this process)?
What you’re asking: Is the automation requester actually allowed to change the process? Is the final decision-maker involved to help ensure that a change to this piece of the process doesn’t impact something critical that happens afterward?
Why it matters: Salesforce is an enterprise-wide solution, where a change to one thing often impacts another. That much is obvious. But the real reason this is on my checklist is because end users often have great ideas to improve their universe and they’re probably not the first person in that seat to have that idea. Does their idea conform to whatever policy or requirement that led to the annoying or inefficient thing you’re trying to fix in the first place? Does changing this annoying or inefficient thing break something critical downstream that this person is unaware of? I’m not saying don’t fix annoying and inefficient things…just make sure your fix is a real fix rather than one that pushes the problem around.
2. How much of this process is “always” or “never” (versus “mostly except for the exceptions”)?
What you’re asking: Are you sure that you’re not going to have me go back and rework this automation when you suddenly remember something it actually shouldn’t apply to?
Why it matters: In my experience, whatever causes the pain is the only thing the user requesting the change will focus on. If you simply address that pain point, you are highly likely to miss other, similar use cases that should be treated differently. This leads to rework and whac-a-mole coding as you chase down these overlooked use cases that were just fine until your automation broke them.
3. Can the requester walk you through it in Salesforce with manual data entry?
What you’re asking: Open a real screen. Show me the exact fields with the exact values you use to make the decision you’re asking me to automate. Does everything we need actually already exist?
Why it matters: Automations rely on a predictable series of steps being completed. Usually they rely on a very specific change or set of changes to a record.
If the necessary fields aren’t already there, you can obviously add it…but wave a huge red flag if you’re automating a process that isn’t already being manually managed. Remember that automating an unclear process makes it more unclear. If the data is not currently being manually managed, take that step first before automating! Otherwise you’ll automate too soon and have to unwind and rebuild everything you just put in place.
Also, you might imagine I also have a checklist for adding these new fields. You might imagine correctly!
4. Can you build a list or report that shows all of the records to be acted on?
What you’re asking:
Which records that should show up don’t?
Which records that do show up shouldn’t?
Are there patterns? Do those patterns need to be incorporated into your logic?
Can you use the information on the list to bulk edit or bulk change the data that you want to automate?
Why it matters: When you can build lists that show all of the records that should match your rules, you can very easily see if your rule applies to 100% of the records impacted or not. You can also poke holes in question #3 to confirm that truly, really, actually every field that is important exists.
Bonus points: You can use these lists to monitor for problems and create discrepancy reports to catch stuff that happens less than 5% of the time but would require complex and elaborate logic to crapify your new automation if you were to try to automate for it. You can use these lists to bulk load changes that mimic the outcomes of your automations, to confirm with users before you automate. Truly, make a report or list view before you automate, it will save you so many tears.
Congratulations! You might have an automation candidate!
You can obviously do some very complex stuff with Flows and Process Builders. The more power they pack into Flow Builder, the more we automate. I have spent a lot of time as a sheepish Mickey Mouse looking hopelessly at rooms full of brooms of my own making. I have spent a lot more time cleaning up my own automation messes. Don’t be afraid to say “not yet!” when asked for some new magical thing.