If you’re a Salesforce #AwesomeAdmin, you know that Salesforce isn’t consistently ranked as the world’s #1 CRM by accident. Its out-of-box performance is great, but the real power of Salesforce lies in its near-infinite customization capabilities. As an admin, you can configure Salesforce to help optimize almost any business process you can think of.

When you bring automation into the picture, things get even more efficient. Using automation in Salesforce makes both you and your users’ lives easier by shifting focus away from monotonous, repetitive tasks, and freeing up time to do much more valuable work. The best part? You don’t have to be a developer to implement it -- using Process Builder, you can automate some incredibly complex actions without writing a single line of code. 

Although there are other automation tools available within Salesforce -- Workflow Rules can automate simple tasks, and Flows or Apex can automate more complex tasks -- Process Builder is important because it’s easy to use and can accomplish most of what the other tools can. Here are some of our best practice recommendations for using Process Builder to streamline automation in your Salesforce org (and if you’re just beginning, check out this awesome Trailhead course to get started!).

You Might Also Like: Work Smarter Not Harder -- The Salesforce Help Your Team Needs

Use One Automation Tool Per Object

Our first best practice recommendation for using Process Builder is to, well, use Process Builder! Alright, we’ll be more specific: you should avoid using multiple automation tools on a single object in order to avoid conflicting automation actions. Workflow rules, flows, and apex are all useful for different reasons, but using a combination of them all for one object is generally a recipe for errors since you can’t be sure of the order in which they execute. For example, if you’re using Process Builder to automate emails on the case object, you should try to use it for any other automation requirements you have for that object.

If you’re transitioning from workflow rules or apex code to Process Builder for an object, make sure to deactivate the old workflow rules or apex before activating your new processes. If you keep them all running at once, you could get unexpected results such as overwritten records.

Organize Your Processes By Function

Process Builder is great because of its relative simplicity and ease of use -- you don’t have to be a developer to use it, and the learning curve isn’t nearly as steep as that for flows or apex. However, once you start creating lots of different processes, it can get a bit confusing, especially when you need to go back and troubleshoot something. 

For this reason, we recommend that you categorize your processes into three groups: initiators, actions, and subprocesses. Ideally, all of your processes will fall into these groups.

Initiators

Initiators are processes that only happen when a new record is created. 

Initiator processes ensure that you get a consistent workflow each time a record is created for a specific object. Ideally, you’ll only have one initiator process per object that accounts for all of the different important record creation scenarios. The best part about using one initiator process per object is that you can control the order in which your criteria are evaluated; separate processes cannot be ordered.

Use the criteria nodes to tell your initiator process to complete different actions based on what type of record is created. If the “Type” field was an important differentiator for the account object, you’d build out your initiator process like this:

When an account record is created, your initiator process will be invoked, and it will check the account type to determine what action to take. In this example, it will first evaluate to see if the type is Customer - Direct. If this is true, it will execute certain actions; if not, it’ll move on to Customer - Channel, and so on. 

Later on, if a user encounters problems during account record creation, you’ll know to go back and check your initiator process first to troubleshoot the problem. Or, if you need to make changes to automated actions that occur during record creation in the future, you’ll know exactly where to go. See how we’re keeping things organized?

You Might Also Like: What Salesforce Document Automation Can Teach You About Embracing Change

Actions

Action processes should be the meat of your business operations. These will execute throughout the lifecycle of your object records as they’re updated to reflect different stages of your business processes. Let’s say you’re employing automation for your quote object. There’s likely different actions that need to be taken at different stages of the quote.

This is where your action processes come into play. These can be designed similarly to your initiator processes. The main difference here is that they are invoked when records are edited or updated. You can use action processes for all actions that take place after record creation. Organize them in a way that reflects the different stages of your object so that the process is easy to understand later.

Subprocesses

Subprocesses are processes that are only invoked by other processes, and not by record creation or updates. These are useful because you can reuse them in multiple different processes if you have repetitive automation actions that fit multiple different scenarios.

Let’s go back to our account initiator process. Although we used the account “Type” field as the criteria to complete different actions, maybe we always want to send a welcome email to all new accounts no matter what type they are. By building an email-send subprocess, we could simply invoke this process as part of each account type’s action group.

In this example, we created a subprocess that will send a welcome email to an account, and referenced it in our account initiator process for every account type. Subprocesses save a considerable amount of time and should be used wherever possible. 

Click here for an in-depth explanation of these grouping conventions from Salesforce’s head of Growth Solutions Engineering, Alex Peattie

Use Naming Conventions

Creating process categories is great, but they won’t be all that useful if you can’t easily identify which process is which. Create a naming convention for each type of process, such as “ObjectName Initiator,” and enforce it across all processes that you develop. This will make your life much easier when you go back to edit or troubleshoot different processes.

Combine As Many Actions As Possible

Process builder is simple to use, and the way you configure it should be as simple as possible, too. Just as you should ideally combine all record-creation processes for one object into the same initiator process, you should try to combine actions together as much as possible. What do we mean by this? 

Let’s say you want to update an account’s address. Instead of creating several actions for each address field, combine them all into one action that updates all of the fields at once.

This is a convention that you should use throughout your entire experience with Process Builder: when you can combine things together, you should. The fewer number of actions you use, the smaller chance you have of running into org limits. 

Account For Infinite Loops & Unintentional Updates

Sometimes your processes can have unintended consequences. If you can catch these mistakes before activating a process, you can save yourself valuable time down the line. When you’re using processes that invoke subprocesses, ensure that these subprocesses don’t have actions that might invoke the original process again, thus creating an infinite loop. These can easily cause your org to go over its limits.

Additionally, look out for multiple processes or actions that update the same field, as unintentional overwriting is a possibility. 

Finally, take note that scheduled actions will be cancelled if their criteria changes from true to false. If you’re using scheduled actions, make sure that there aren’t any immediate actions that might affect their criteria and potentially cancel them unintentionally. 

Test, Test, Test! (In A Sandbox)

As with any big updates that you make in Salesforce, we recommend that you use a sandbox to test any new processes or updates to old processes. Process Builder is a powerful tool, and it has the potential to save countless hours of valuable time -- but because it’s so powerful, it also has the potential to break things if it’s not configured properly. So jump into a sandbox and try to break it -- test as many scenarios as you can think of until you’re positive that your work is production-ready. Then, deploy your new process to your team. The time that everyone saves will speak for itself!

S-Docs: The Document Automation Tool You’ve Been Waiting For 

S-Docs is a 100% native document automation and e-signature solution that’s purpose-built for Salesforce. Since it’s built on the Salesforce platform, S-Docs works seamlessly with Process Builder to automate documents, emails, and e-signature requests for virtually any use case or industry, from financial services to healthcare to the public sector. Automate invoices, quotes, proposals, contracts, medical documents, regulatory forms, or any other mission-critical document, and stop worrying about using up your valuable time on this error-prone task.

Get in contact with us today to learn about the full feature functionality of S-Docs and experience all that it has to offer. 

Try S-Docs today.

First two templates are free!

Download Now

Read More

Blog
October 23, 2020

How To Create A Stunning Statement Of Work In Salesforce

Certain documents just make life easier. For salespeople, these include sales quotes and invoices. For…
Blog
October 19, 2020

Salesforce Influencer Spotlight: Melissa Hill Dees

Welcome back to another S-Docs Salesforce Influencer Spotlight, where we highlight some of the most…
Blog
October 6, 2020

Salesforce MVP Spotlight: Scott Luikart

Welcome back to another S-Docs Salesforce MVP Spotlight, where we highlight some of the most…