Process Builder – The Salesforce Swiss Army Knife

In the Winter 15 release, Salesforce introduced a game changing tool for admins. The Lightning Process Builder has allowed clickers to create more functionality and close the gap with coders. Personally, I have a limited coding background; I can read and understand code, and can write basic code if necessary, but I greatly prefer using Process Builder and other tools to complete the task. While Process Builder is more complex than Workflow Rules, it is simpler to maintain than Apex. I have also found that most customer admins prefer using Process Builder to coded solutions.

Process Builder is a powerful tool that can easily extend functionality within an org, but it is certainly not perfect. There are some quirks and shortcomings (such as error handling), but that discussion will be saved for another day.

After working with Process Builder since its inception, I wanted to share a few of my favorite features within the Process Builder interface, how it can extend functionality, and how it can be used in conjunction with other tools.

Before we jump into the features, let’s setup a test process for our use cases. The process will be named “Opportunity – Evaluate Stages” and it will execute a predetermined set of actions based on the current opportunity stage. Notice the naming convention for the process: “Object – Short Description”. By using this naming convention, it will allow you (and future admins) to easily identify which object is affected and what occurs in the process.

process-creation

Multiple Criteria Evaluation in a Single Process Builder

One of the biggest advantages a process builder has over a workflow rule is that it can contain multiple If/Then statements. This allows admins to simplify the infrastructure by combining multiple workflow rules into a single process builder. Not only can you combine multiple evaluations into a single process builder, you can also independently set each set of criteria to either stop or move on to the next evaluation (circled in red).

multipleevaluations

Drag-and-Drop Criteria Reordering

In the early phases of Process Builder, you had to plan how you built the criteria steps because it was not easy to reorder them. In order to raise an evaluation to the top of the process you would have to delete and recreate all previous criteria. After the release of Spring 16, admins breathed a collective sigh of relief since the drag-and-drop reordering was made available. Just like in reporting, the object being dragged turns partially translucent and a green line appears where it will land (purple and green arrows).

reordercriteria

Reusable Processes

Up until the Winter 17 release, this was one advantage workflow rules had over process builders. Workflows could reuse functionality (field updates, email alerts, tasks) on a per object basis. Winter 17 took this concept and expanded it to all actions available within the Process Builder.

The first step is to create the invocable process. The only difference from a regular process builder is on the initial New Process screen – indicating that the process starts when it is invoked by another process (shown below). In this example, the invocable process will create a task called “Email Client” and assign it to the opportunity owner.

invocableprocess1

Once the invocable process is built, it can be called from one or multiple actions in any number of flows. You simply select the action type of “Processes” and then pick the desired invocable process (red below). Once this action is saved, the task will be created on every opportunity that enters the “Value Proposition” stage. If this task needs to be created on any variety of tasks, it can be added to an action during each criteria evaluation step.

invocableprocess2

Launching Flows

Visual Workflows (flows) are applications built within Salesforce that can perform simple tasks (such as creating or updating records) or execute complex functionality (automating complex business processes or gathering user inputs to evaluate data). Flow is one of, if not, the most powerful and complex tools a non-coding Salesforce user can utilize to expand functionality. Since it has a high level of complexity, admins of all skill levels often shy away from using it. If you are unfamiliar with flow or would just like a better understanding, I recommend starting with the Winter 17 Visual Workflow Guide.

In our example, we will call a simple flow that closes all open tasks on an opportunity when the status is set to “Closed/Lost”. First we have to build the flow, save it, and activate it before it can be launched from a process builder. This flow will be called “Opportunity-Close Tasks”.

flowexample

Once the flow is saved and activated, we need to go back and create the action in the process builder. By selecting “Flows” as the Action Type, we can now identify which flow to launch and pass values to necessary variables. In this case, we are going to pass in the Opportunity ID into the flow so the flow will know how to find the tasks related to the opportunity. This flow will now launch every time the stage on an opportunity is set to “Closed/Lost”.

launchflow

Updating Multiple Related Records

The ability to update records seems to be a simple functionality that all admins would use, but I only recently discovered how powerful of a function this could be. I had originally only used it to update a single related record and accidentally found out that it can update every related record on a specific object.

In our testing environment, we will assume we have configured an opportunity to have multiple child opportunities. This will allow us to related many opportunities to a single parent.

The business requirement is to have an opportunity set to private when the opportunity stage is set to “Negotiation” and if the parent opportunity turns private, then all children must also become private opportunities. We need to define the action the same way as updating a single related record, except when we select the Record Type to update. When selecting which record(s) to update, we need to make sure we select the option with the suffix of “__r”. This will tell the process to update all records using that relationship in one motion.

closechildopps

Summary

We have just reviewed a subset of functionality available within Process Builder and, truth be told, a summary could be written on almost each piece individually. My hope is that your interest is piqued enough to see how some of the simpler features of Process Builder could help you improve automation within your org. I encourage you to try each type of action and read the related documentation to obtain a thorough understanding of the idiosyncrasies of the functionality.

Process Builder is a powerful and valuable tool that all admins should have at their disposal when evaluating requirements and designing solutions.

Leave a comment