With Winter 17, we can now build reusable processes with the introduction of invocable processes! We now have the ability to build DRY solutions. Hooray!

We interrupt this blog post for an important message…

Jen Lee will be presenting a Release Readiness Webinar, Keeping it “DRY” with Reusable Processes, on December 13th at 10am PT/1pm ET.

Register by clicking on the image below.

Now, back to our regularly scheduled program…

There are two reasons why you may want to use invocable processes:

1. Modularize sections of your processes. Call it from multiple processes or from multiple action groups in the same process. Update those actions in one invocable process, all processes then use the updated actions.
2. Implement simple nested if/then statements using invocable processes. Rather than build and invoke a flow or write code, we can now build a second level of logic into another process.

This blog post will focus on a use case that satisfies the second reason listed above.

I’ve also written a blog post that focuses on a use case supporting the first reason entitled “Minimize “DRY” (Don’t Repeat Yourself) in Process Builder by Building Reusable Processes.”

Here are a few lessons learned from implementing the use case:

• Build reusable processes to minimize initial setup time and later on, re-work/ maintenance time.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes providing the purpose of a process builder, etc.

Business Use Case: Addison Dogster is the system administrator at Universal Containers. Sally Sunshine is the Sales Manager. Sally provided the following requirements for Addison to automate in Salesforce.

Solution: 

As everyone who’s worked in Salesforce knows, there are several ways we can solution requirements. That’s the flexibility of the platform.

Addison laid out the following design based on the requirements.

She decided that process builder would be used to solution the requirements.

As Addison thinks ahead about the growth of her org, she foresees that there will be additional lead processes that will be automated and as a result, more criteria nodes will be added to this process. She knows that based on the way she’s configured the process, when Salesforce executes the process, it will go through and evaluate all 5 criteria nodes every time a lead is created or edited. While evaluating 5 criteria nodes may not cause any performance issue, evaluating many, many more may. Addison notices that there are common criteria in a couple of criteria nodes and decides to improve performance by minimizing the number of criteria nodes from 5 to 3.

In this case, the new lead criteria appears in two criteria and the status is changed and the status is “Open – Not Contacted” applies to two criteria. These can be used as the first level of if/then logic. This will consolidate the nodes from 5 to 3.

Prior to Winter 17, Addison would have to introduce the second layer of if/then logic by invoking flow or writing apex. Since Addison is an #AwesomeAdmin, she delivers her solution declaratively before going to code using process builder and two visual flows.

Here is her process builder and visual workflow solution:

This is the flow that is invoked in the first criteria (new leads)…

This is the flow invoked in the second criteria node (when the status changed and the status is “open – not contacted”)…

If Addison built her solution in Winter 17, she can leverage the feature of invocable processes in Process Builder. Rather than building and invoking flow (which is an intermediate admin skillset), Addison can now build two invocable processes and call these processes from the “master” process.

Here is her updated process builder design:

Here is the improved, built “master” process builder, collapsing four criteria nodes to two, both invoking separate processes. The last criteria node remains unchanged.

This is the new lead invocable process…

This is the invocable process for the lead status change process…

The below are quick steps on how to replicate the improved solution in your org and tweak it for your own purposes. Since the focus of this blog post is about invocable processes, the steps below will only cover setting up the invocable process and invoking a process from the “master” process.

Quick Steps:

1.Let’s first create the first invocable process – New Lead. For those using Salesforce Classic, process builder can be found in Create | Workflows & Approvals | Process Builder. In Lightning Experience, it is found under Process Automation | Process Builder.

A. Set your process to the following and save:

Process Name: New Lead

Description: Invocable process when a new lead is created

The process starts when*: It’s invoked by another process.

B. We are going to select the “Lead” object and Save. Because this is an invocable process, unlike the “when a record changes” process, there is no further option to select when a record is created or record is created or edited. Invocable processes will just execute.

C. Set the first criteria node when the lead source = phone inquiry.

Criteria Name: Origin = Phone

Criteria For Executing Actions: Conditions are met

Set Conditions: [Lead].LeadSource equals Picklist Phone Inquiry

Conditions: All of the conditions are met (AND)

The end result looks like this…

Then, for the immediate action, we will update the “Date Assigned to CSR” field to today’s date. Configure the immediate action to the below and save.

Action Type: Update Records

Action Name: Update Lead

Record Type: “Select the lead record that started the process”

Criteria for Updating Records: No criteria – just update the records

Field: Date Assigned to CSR formula today()

The end result looks like this…

D. Now, we need to create the second criteria node, email is not blank. Configure it to have the information below and save.

Criteria Name: Email is not blank

Criteria for Executing Actions: Conditions are met

Field: [Lead].Email is null Boolean False (Note: This means that the email is not blank.)

The end result looks like this…

For the immediate action, we are going to configure it to send an email alert (the email template and alert were set up in advance).

Action Type: Email Alerts

Action Name: Send Email

Email Alert: <select the email alert>

The end result looks like this…

E. Because we want Salesforce to evaluate both criteria nodes and execute if the situation is met, we need to go back to the first criteria node, click on “Stop” and set it instead to “Evaluate the next criteria” and save.

F. We are done with the set up of our first invocable process. Let’s now click on the “Activate” button to activate the invocable process so it can be referenced later in the “master” process.

2.Let’s create our second invocable process – Lead Status Process. For those using Salesforce Classic, process builder can be found in Create | Workflows & Approvals | Process Builder. In Lightning Experience, it is found under Process Automation | Process Builder.

A. Set your process to the following and save:

Process Name: Lead Status Process

Description: Invocable process that runs when a lead status is changed, lead status = open – not contacted

The process starts when*: It’s invoked by another process.

B. We are going to select the “Lead” object and Save.

C. Set the first criteria node when the rating is hot.

Criteria Name: Rating = Hot

Criteria For Executing Actions: Conditions are met

Set Conditions: [Lead].Rating equals Picklist Hot

Conditions: All of the conditions are met (AND)

The end result looks like this…

Then, for the immediate action, we will create an event. Configure the immediate action to the below and save.

Action Type: Create a Record

Action Name: Create an Event

Record Type: Event

Criteria for Updating Records: No criteria – just update the records

Fields:

End Date Time Formula [Lead].LastModifiedDate  + 3 + 10/24 (Note: I set this to the last modified date of the lead record plus 3 days and 10:00AM)

Assigned to ID Reference [Lead]OwnerId

Start Date Time Formula [Lead].LastModifiedDate  + 3 + 9/24 (Note: I set this to the last modified date of the lead record plus 3 days and 9:00AM)

Subject Formula ‘Meeting with Lead:’  + [Lead].FirstName + ‘ ‘ + [Lead].LastName

Name ID Reference [Lead].Id

The end result looks like this…

D. Now, we need to create the second criteria node, rating is warm. Configure it to have the information below and save.

Criteria Name: Rating = Warm

Criteria for Executing Actions: Conditions are met

Field: [Lead].Rating Equals Picklist Warm

The end result looks like this…

For the immediate action, we are going to configure it to create a task.

Action Type: Create a Record

Record Type: Task

Action Name: Create a Task

Fields:

Due Date Only Formula Today() + 3 (Note: This will set the date to 3 days from today’s date)

Assigned To ID Reference [Lead].OwnerId

Priority Picklist Normal

Status Picklist Not Started

Subject Formula ‘Follow up with the Lead -‘ + [Lead].FirstName + ‘ ‘ +  [Lead].LastName

Name ID Reference [Lead].Id

The end result looks like this…

E. We are done with the set up of our second invocable process. Let’s now click on the “Activate” button to activate the invocable process so it can be referenced later in the “master” process.

3.Lastly, we need to create our “master” process called New/Updates to Existing Leads. For those using Salesforce Classic, process builder can be found in Create | Workflows & Approvals | Process Builder. In Lightning Experience, it is found under Process Automation | Process Builder.

A. Set your process to the following and save:

Process Name: New/Updates to Existing Leads

Description: Process to run when there are new or updates to existing leads

The process starts when*: A record changes

B. We are going to select the “Lead” object, when a record is created or edited and Save.

C. Set the first criteria node when the rating is hot.

Criteria Name: New

Criteria For Executing Actions: Formula evaluates to true (This is so we can use the syntax “IsNew()”)

Build formula: IsNew()

The end result looks like this…

Then, for the immediate action, we are invoking the New Lead process. Configure the immediate action to the below and save.

Action Type: Processes

Action Name: New Lead Process

Process: New Lead

Set Process Variable: SObject Reference [Lead] (Note: Select “Select the Lead record that started your process”)

The end result looks like this…

D. Now, we need to create the second criteria node, where the status is changed and the status is open – not contacted. Configure it to have the information below and save.

Criteria Name: Status = Open, Not Contacted

Criteria for Executing Actions: Conditions are met

Fields:

[Lead].Status Is changed Boolean True

[Lead].Status Equals Picklist Open – Not Contacted

Conditions: All of the conditions are met (AND)

The end result looks like this…

For the immediate action, we are going to configure it to invoke the second process – Lead Status Process.

Action Type: Processes

Action Name: Lead Status Process

Process: Lead Status Process

Set Process Variable: SObject Reference [Lead] (Note: Select “Select the Lead record that started your process”)

The end result looks like this…

E. Lastly, we need to create the third criteria node, where a lead’s ownership is assigned to Jennifer Lee. Configure it to have the information below and save.

Criteria Name: Owner = Jennifer Lee

Criteria for Executing Actions: Conditions are met

Fields:

[Lead].Owner:User.FirstName Equals String Jennifer [This uses the new Winter17 feature where you can drill into fields associated to the owner]

[Lead].Owner:User.LastName Equals String Lee [This uses the new Winter17 feature where you can drill into fields associated to the owner]

Conditions: All of the conditions are met (AND)

The end result looks like this…

For the immediate action, we are going to configure it to invoke the second process – Lead Status Process.

Action Type: Email Alerts

Action Name: Send email

Email Alert: Send_Email_To_Jennifer Lee

The end result looks like this…

F. We’re done. Let’s now click on the “Activate” button to activate the “master” process.

That’s it! Congrats! You’ve implemented a process that invokes another process.

Now, before you deploy the changes to Production, don’t forget to test your configuration changes.

Deployment Notes/Tips:

• Process builders can be deployed to Production in a change set (or can be deployed using a tool such as Dreamfactory’s Snapshot).
• Activate the process builders as they are deployed as inactive into Production.