Overview

In our last article, we talked about how easy it is for process builders to bloat over time, causing significant technical debt and Apex CPU timeouts. In this article, we want to guide you through what that process of consolidation actually looks like.

This is unfortunately not a project you can expect to be wrapped up in a couple of weeks. In our experience, each individual object will take from several weeks to several months to work through, depending on how complex the logic is and how many automations you need to consolidate.

With that said, if your process builders are causing you trouble, it’s generally worth it. We’ve seen reductions in errors of up to 95% following this exercise.

One Quick Side Note

As we’ve mentioned in other articles, Salesforce now recommends building in flow as opposed to process builder, except in the case of functionality gaps. If you have not yet begun building automations or have only basic processes built in your instance, we recommend making the switch to flow now.

For orgs that are suffering from the adverse effects of process builder bloat, but can’t yet move to flow, going through the exercise of consolidating your process builders will most likely still have a short term net gain. For this reason, we recommend going ahead and consolidating what process builders you can now whilst also making a longer-term plan to move over to flow in a couple of release cycles.

Step 1: Take stock of the situation

The first thing you want to do is understand the situation you’re in. How many active process builders, workflow rules and flows are you actually looking at in your org?

Throw all of the processes into a spreadsheet and start categorising them by process type and by object (where possible – this is harder to do with flow). Once you’ve completed this exercise, you should be able to see how many individual processes you have running on each object in your org and which objects are the worst affected.

Step 2: Familiarise yourself with the framework you’ll be using

As we’ve mentioned before, we use this framework to reconfigure process builders into a more logical and maintainable structure. If you have a different framework you prefer to use, that’s fine. The important thing is to be very clear on the criteria you’ll be using to transition your processes from their current state to their new one.

If working as part of a team on this project, it may help to write down the criteria you’ll be using to make decisions about how to rebuild each process builder and ensure each team member is on board with the approach. This avoids complications that may arise through each person following their own method.

Step 3: Take it one object at a time

While it can be helpful to look at your automations holistically, it will generally be too complex and/or risky to work on, test and deploy changes across multiple objects at the same time.

We usually work on a single object at a time, moving on to a new object once the first has been fully deployed and verified as working correctly.

When choosing which object to start with, if you’re new to this type of project, we recommend working from the least to most complex object. In other words, start with one of the objects with:

• The fewest processes
• The least business impact

This will allow you to get in some practice and perfect your method with minimal risk.

If you’re comfortable with this process and there is a strong business need to start with a specific object (e.g. you’re having lots of Lead errors), feel free to start there instead.

Step 4: Document the current state

This is the process we go through to document what is actually happening on that object and lay the groundwork to streamline the process. For this example, we are assuming we’re working on the Lead object.

You can use this template as a frame of reference.

For each automation that fires from the lead:

• Document everything you find – criteria, actions, action-level criteria etc
• Make note of each field which triggers an action
• Make a note of each field which is updated by the actions
  • If the field update is on a different object, make a note of that too
• Where possible, log which of the three new process builders that action belongs to. If you’re unsure, come back to it later.
  • Lead Initiator Process Builder IF it triggers on the creation of a lead
  • Lead Processor Process Builder IF it deals with Lead-lifecycle changes
  • Lead Actions Process Builder IF it deals with non-lead-lifecycle changes
• Make a note of criteria that could be consolidated
  • These could be criteria that execute on the same set of fields, under the same conditions or on the same object
• Make a note of formulae that could be built using the out of the box PB criteria instead, since moving from formula to PB criteria will improve execution speed
  • For example, logic that doesn’t involve ISNEW()

Once you’ve completed this exercise, you should have a list of everything that is happening on the lead object and a first idea of where each action might fit under your new framework.

You’re now ready to start documenting the new process builder architecture.

Step 5: Document the ideal state

Once you have combed through your existing automations and made some decisions about where each node should be moved to, you can start mapping out what your new process builders will look like.

As a reminder, the general framework you want to use is:

• An Initiator PB, which executes only on record create
• A Processor PB, which is responsible for the main ‘lifecycle’ of the object. For opportunities, this is likely going to be stage and forecast category changes. For leads, it might be status or marketing funnel stage.
• An Actions PB, which is responsible for miscellaneous actions that don’t fit the main lifecycle of the object.

Create a tab in your spreadsheet for each new process builder and begin moving the existing actions into either the initiator, processor or actions PB. Here the notes you made previously grouping actions and action triggers together, as you will likely be able to consolidate a lot of actions into a single node.

For example, on the opportunity object, you will likely have a set of actions that occur upon stage change. Depending on their complexity, you may be able to move all of those actions into a single node, rather than having many separate nodes or process builders that essentially execute under the same criteria.

This process will likely take a few run-throughs to get to a place where everything makes sense and you’re happy, which is why it’s better to do in a spreadsheet than in process builder itself. It’s much easier to add, delete, split out, merge or reorder nodes in a spreadsheet than it is in Salesforce.

Step 6: Build your new process builders in UAT

Once you have your ideal state mapped out, you can go ahead and start building the new PBs.

If you see the need to rename nodes, aim to have titles that reflect the trigger. For instance:

• DO: Node Name: Lead Reaches Silver => Action: Add to Silver Engagement List
• DONT: Node Name: Add Lead to Silver Engagement List => Action: Add to Silver Engagement List

This will make it easier for future you to identify which node would fit the criteria for new actions. If you use a naming convention, make sure to document it somewhat. Future you will appreciate this!

Some other general points you’ll want to bear in mind are:

• Use the Evaluate The Next Criteria option sparingly, as his can blow up the time it takes your process builder to calculate
  • Try to group such actions together and apply changes in a logical order
• Use the out of the box formula builder where possible as opposed to writing your own formulae
  • Process builders evaluate faster this way and are easier to understand and debug
• Minimise cross-object updates
  • There are costly performance-wise and can trigger recursive updates between objects
• Move actions that don’t need to be completed immediately into scheduled actions

More information can be found in this article.

Step 7: Customer review

Once you have finalised your new architecture, you will want to review this with your customer or internal stakeholders.

We always provide the customer with documentation of the before and after processes to ensure they are comfortable with the changes we are making. Often you’ll find through doing this that there are reasons why some action needs to happen before record save and therefore stay in a flow or workflow rule, why the criteria should be more permissive or may even just have questions about the logic.

When you do pass your documents on for review (either to the customer or a manager) we found it useful to also include a map of where the old nodes have been migrated to and what they are now called.

Once your customer has approved the changes, you can move on to next step.

Step 7: Test your new build in UAT

Testing is going to be the last step you will need to give a lot of attention to.

This stage is usually when we make use of a nifty google chrome extension called Salesforce Inspector. It has a feature that displays all the values in fields regardless of page layout plus the added benefit of not just showing you the Label but also the API Name and the data type. This is particularly useful in avoiding changes to layouts.

Generally, we like to go through, testing and documenting the ‘before’ behaviour, following by the ‘after’ behaviour to compare the two.

The order in which we test can be simplified as follows:

1. Make sure NEW PB is deactivated
2. Make sure OLD PBs are active
   • Find/create a test record and set the field values to match the OLD Criteria – take screenshot or document what values were set in which field (Status = Silver, First Silver DT is blank)
   • Document expected result (i.e. Lead Campaign field populated )
   • Save the record
   • Check if the field Lead Campaign updated accordingly.
3. Make sure OLD PB is deactivated
4. Make sure NEW PB is active
   • Find/create a test record and set the field values to match the OLD Criteria – take screenshot or document what values were set in which field (Status = Silver, First Silver DT is blank)
   • Document expected result (i.e. Lead Campaign field populated & Lead.First_DT_Silver__c = NOW())
   • Save the record
   • Check if the field Lead Campaign updated accordingly.

We recommend this method because:

• You don’t lose any of your original processes and can still refer back to them as needed
• You can test node by node
• You can compare each action like for like, which makes it easy to identify differences in behaviour between your PB versions

Step 7: Deploy and retest

Carve out at least a day to deploy and try to block some time throughout the coming week so that, if issues arise, you will be available to investigate them.

Additionally, where possible, choose a time to deploy when the fewest users are working within Salesforce and avoid deploying at times of the month where:

• Users need to complete certain activities on a timeline (e.g. end of the quarter for salespeople)
• You are lacking resources to address any issues that arise

It may go without saying, but we recommend deploying one object at a time. Add your newly-consolidated and tested process builders to a change set and send them over to production. Once in production, deactivate all old process builders and activate the new process builders. Make a note of your actions as you go in case you need to revert the changes.

Repeat the same testing that you completed in UAT to check the functionality of the process builders. Even if you have tested thoroughly in a sandbox, it’s still quite common for production to be different in some ways to your sandbox environment. For example, you might have something like a Hubspot or Marketo connection that only works in production and which was impossible to test in sandbox.

While testing, mark any errors you find and address them in order of priority, testing again after each change until all bugs have been resolved. Make sure to keep an eye out for error emails or reports from users that something isn’t working.

Step 8: Rejoice

It’s been a slog, but finally you should be in a place where your process builders have been rebuilt in such a way that performance errors have been minimised and you and your team have a clear structure to follow for any changes going forward.

Give yourself a well-deserved pat on the back and enjoy the feeling of not having to work on your process builders again for a good long time!

Any questions about this article? Feel free to get in touch with us via our Contact Us form.