Process Builder Best Practices Tutorial – Reduce, Reuse, Recycle: Extended

While Salesforce has had process automation at the core of its offering for quite a long time, it wasn’t always as clean, intuitive, or well-organized as it is nowadays.

In my previous article: “Reduce, Reuse, Recycle Your Automations with Salesforce Process Builder”, I described some guidelines for how we can use the Process Builder to make our lives as administrators and developers much easier. In essence, while workflow rules were powerful and provided a lot of functionality, they were also pretty opaque, difficult to maintain, and update. So, let’s get practical; if you read my previous post, you know why and when you might use Process Builder. But you might not yet know exactly how.

Deactivating and deleting workflow rules can be just as scary as it is exhilarating, but I’ll show you how we can take the “Three R’s” framework I introduced and put it into practice today to make your Salesforce org cleaner, more easily understood, and ever-more extensible.

Reduce

First, recall that Process Builder helps us reduce development time, complexity, and the difficulty of troubleshooting.

To see this in more detail, let’s show an example.

Let’s say that we want to set a field value depending on the record type of a newly created lead, and that we have 3 different record types.

First, we’ll start by navigating to Setup > Process Automation > Workflow Rules to see a list view of our active and inactive workflow rules.

If you’re lucky, maybe yours looks manageable like the above, with a relatively clear naming scheme so that you don’t have to spend too much time hunting down exactly which workflow rule to edit when you need to make a minor change.

In the list above that we see the three separate workflow rules which are required:

[New Lead] Update A Leads

[New Lead] Update B Leads

[New Lead] Update C Leads

Where my record types are “A,” “B,” and “C.”

Within each of these, I want to set an initial field value, and after a certain amount of hours I’ll change its value. So each workflow rule will require at least two actions, and might appear like this:

I need to go in and create these separate actions for each workflow rule that applies to each record type! It’s a bit of a headache. If I run into an issue, I would be required to deactivate each rule separately, and to deactivate each rule I need to confirm that it doesn’t have any time-based actions queued to run, and if it does, delete those before I can return to deactivate it. I’m exhausted just explaining those dependencies. Quite a headache, even for this simplified example.

Let’s see how we can do this same thing with the Process Builder.

Let’s navigate to Setup > Process Automation > Process Builder and get started.

First, create a new process instance.

And let’s implement the same logic, but instead of three workflow rules, we create one Process Builder instance with three branches corresponding to our three record types.

Ultimately, we will end up here:

There is a way to condense all of this logic into a single branch, but for the sake of future maintainability and easy visualization of the logic, I’ve chosen to keep each branch separate.

Reuse

Be a protector of the sacred DRY principle! Reuse logic, nodes, and Apex code so that your Salesforce org represents a well-designed system of highways rather than the jumbled up earbuds you just pulled out of your pocket.

Let’s continue with what we built above. Let’s say that, after a 24, 48, or 72 hours when the status is “Missed,” we want to alert the sales manager. What are our options?

1. Add 3 or more time-based actions to the existing Process Builder instance
2. Create an invocable subprocess to contain all of that logic and call if from our “master” instance.

Since we’re demonstrating the principle of reuse, and since we are savvy admins who know that in the future it will benefit us greatly to build in a modular manner, we opt for the second option.

First, a new subprocess.

And an opportunity to utilize custom logic:

See where it says (1 OR 2 OR 3) AND 4? We’re referring to the conditions listed above, and essentially saying “any of the record types A, B, or C, which have not been contacted promptly.”

And of course, adding our action.

And definitely the coolest part: embedding it in our master process. Note that we can drag the node to the top to make sure that it is evaluated first, and we can then set the process to continue evaluating.

Well! Quick recap: we made a process and an invocable subprocess, and we embedded the latter in the former. Wasn’t so hard, now was it? That’s reuse, in a nutshell.

Recycle

Now, for a bit of catharsis, we send those old workflow rules to the recycle bin and move one step closer to that clean, manageable, modular org we always dreamed about. Quick reminder, to delete a workflow we should:

1. Deactivate.
2. Check to see if there are time-based actions queued for execution.To see this, Navigate to Setup > Environments > Monitoring > Time-Based Workflow
3. Delete.

Goodbye!

A Few Caveats

I don’t want to get ahead of myself. I’m an advocate of the Process Builder, because it’s personally made my life much easier. With that said, there are still a few instances when you might have an easier time using a workflow rule rather than trying to leverage Process Builder, and you may achieve better performance. An obvious example is sending outbound messages without having to write any code, which workflow can still do but process builder will not.

Additionally, because of the flexibility of the Process Builder, there can be more than one way to automate whatever it is what you want to automate. While this does introduce some ambiguity, it ultimately represents a greater level of flexibility than was available with the previous process automation tools in Salesforce.

As always, it’s important that we call out one of the biggest strengths of the Process Builder: invocable Apex classes. Given that we can pass variable values in a really intuitive manner, Process Builder becomes a tool which can be managed by a savvy admin and simultaneously extended by a good developer, meaning that the possibilities are really endless.

Summary: Last, but not least!

As I suspect many are in the process of doing or will be undertaking soon, migrating workflow rules to the Process Builder is no small task. Planning, organizing, diagramming, and iterating are all steps along the way before you can have that satisfying moment of activating a well-designed and beautiful Process Builder instance. However, remembering that fundamentally we can reduce complexity, reuse commonly utilized logic, and recycle that which is no longer serving a purpose, should provide reason enough to be excited about the prospect.