Guest post: Phil is a Principal Business Analyst at EDL Consulting, a Salesforce.com Professional Services partner. He is a frequent contributor to Salesforce Developers and author of the recently published book Practical Salesforce.com Development Without Code (http://amzn.com/1484200985)

Lightning Process Builder When I was first thrust into the world of Salesforce.com back in 2010, I quickly became enamored with the ease at which I could implement changes to support our organizational processes. It was clear right away that this was the platform for me. I had come from quite the opposite situation with my previous employer; the platform there was a hodge-podge of mostly home-grown applications that boasted hundreds of thousands of lines of code. While there were no governor limits or other supposed “constraints” to what was possible, trying to efficiently maintain and improve functionality and interfaces became a recurring nightmare. Very little was actually configurable; almost every element one would expect to require only a data change would require a code change. At the time, I was responsible for coming up with system changes that would either generate revenue or provide a cost reduction. Every request I submitted had at least a few requirements that contained text along the lines of “future modifications to this setting can be done via configuration (no code changes needed).” The damage had been done, however, and the system inched along like a snail, oblivious to the pace for which customers were pleading.

At the time when I entered the Force.com arena, Workflow was the name of the game for those of in the world of declarative, or point-and-click, development within Salesforce.com. Its output, workflow rules, have been around for a while and have served us well. They are an established, reliable means to develop automated changes follow a business process and continue to be an absolute must-know for all administrators, analysts, consultants, and developers.

That being said, it would be disingenuous to say that traditional Workflow has left little to be desired. The reality is that the Force.com platform has been rapidly expanding, while Workflow has lingered in its comfort zone. We have seen some minor enhancements to what can be done via workflow rules in past releases, but they haven’t had a significant impact on the tool’s value (the one exception to this is inclusion of trigger-ready flows as potential workflow actions, which is a major leap). Not only are there some common scenarios that quickly bring forth chimes of “you need code to do that,” but Workflow now reveals an isolation from newer Force.com elements such as Chatter and publisher actions. Whether you’ve noticed it or not, Workflow has been pining for an overhaul.

The good news is that Salesforce.com has once again done what it has been doing for years: innovate. Process Builder is some of the recent fruit of that innovation. It is a new tool for creating “processes” that support process automation, combining a foundation of Salesforce Lightning with elements of Visual Workflow. The best part? It’s 100% declarative. No code needed. For the technical architects and Apex lovers out there, don’t stop here. This tool is definitely not just for those who avoid code.

I’ll walk through a few use cases and show the Process Builder in action. I first want to share a few points that cover the tool a bit more and explain why it’s so important in the world of Salesforce.com.

Reasons to consider using Process Builder

1. Process Builder does not require use or knowledge of Apex, Visualforce, or any other code.

The birth of this tool clearly shows that the Force.com platform is growing, and doing so in the right direction. Obviously, for administrators, analysts, and consultants developing business process automation solutions, this is a great fit. More tools to develop solutions = happier clients. This takes on a different angle for those of you who self-identify as “technical” resources. I know a number of (very intelligent) technical architects at Salesforce.com and at my company, EDL Consulting, and they can do some amazing things with Apex and Visualforce. So, does this mean that their roles are diminished? Absolutely not. First off, Salesforce.com continues to enhance Force.com customization capabilities with each release. Second, if a declarative tool can remove some of the burden for TAs, it opens the door for using code in new and exciting ways. I see it as a win-win across the board.

2. Process Builder delivers new capabilities that are simply not possible within Workflow Rules.

These capabilities include:

Call an Apex class
Update a lookup record (not just those w/ master-detail)
Update related (child) records
Update a picklist field dynamically (vs selected value)
Create a record
Post to Chatter
Submit for Approval

I could go on about how huge some of these features are, but you probably understand if you’re reading this post. My personal favorites are the abilities to update related (child) records, create a record, and post to Chatter. There are just so many scenarios where these could come into play.

3. Although it does not boast quite the same feature set, Process Builder is quicker and easier to use than Visual Workflow.

Visual Workflow is more powerful than Process Builder, there’s no doubt of that. Visual Workflow is a great tool than handle high amounts of complexity within an automated business process. However, there’s overhead you have to consider when using it. To handle the aforementioned complexity, the tool has a large number of different elements that can be used. The capabilities are impressive, but the interface is not terribly intuitive. Visual Workflow is not a tool that many people just open up and start using with ease. You need to understand how it works and will probably go through a few iterations before you really get the hang of it. Even then, the speed to deliver solutions is limited by the tool itself. To be clear, that is not a knock on Visual Workflow, it’s just the reality encountered with a more powerful, complex tool.

NOTE: Process Builder is not at all a straight replacement for Visual Workflow, as it does not provide all the capabilities that are found within Visual Workflow. You may decide to use it in place of workflow rules, but that decision should only come with significant analysis and thought around your current situation and future needs.

Example Scenario: Automated Child Case Closure

I’ve come up with a scenario using the customer support organization at “Process Builders, Inc.” that intentionally includes some of the functionality that is absent from workflow rules. I would imagine that a number of readers have been through a similar situation and can relate to the need for this functionality via declarative means.

At Process Builders, Inc., the Customer Support organization has the concept of parent cases, something recognized as standard functionality within the Salesforce Service Cloud.

Here are some of the requirements and considerations for the process to be implemented:

Customer Support wants only the parent case to be managed/worked, so child cases cannot be manually closed.
As a result of the sensitivity of cases affecting multiple clients, the closure of a parent case must go through an approval process and be approved before child cases are closed.
The approval process must be automatically built in to the process (i.e., Process Builders, Inc. does not want support agents clicking on a “Submit for Approval” button).
If the closure request is rejected, the parent case will be set to “Reopened” and all child cases will be set to “On Hold.”
If the closure request is approved, multiple actions will occur: 1) All child cases will be closed, 2) An update will be posted to Chatter, and 3) A task will be assigned to the Case Owner.

There are some preparation steps I’ve made, including setting up some record types, custom fields, and validation rules, but I won’t dive into those here. Let’s just say that I’ve added configurations to support proper flow and enforce business rules for this new process. I want to focus on how I’ve used Process Builder to automate what I’ve described above. I will walk through the the process I’ve created and then show how it works for the Customer Support agents at Process Builders, Inc.

Step 1a: Select Case as the applicable object

Step 1b: Configure settings for Case

Step 2a: Configure the criteria for the first set of related actions

The third field above is a custom field called “Close Child Cases” and is used by the dependent actions in 2b, which you will see below.

Step 2b: Add related action #1 (Submit Parent Case for Approval) for the first decision point

This is where the real fun starts. Notice what I’m doing here – submitting this record for approval via an already-established approval process! This is not possible with workflow rules. A successful approval with check a custom checkbox field called “Close Child Cases.”

Step 2c: Add related action #2 (Update Child Cases) for the first decision point

This is not your ordinary field update that we’ve come to know in the context of workflow rules. This action actually updates the related (child) records! When you select “Update a Record” as the action, you can do any of the following:

Update the modified record (itself)
Update a record that is the lookup record within a Lookup relationship
Update a record that is the detail record within a master-detail relationship
Update related child records

Workflow rules were able to handle the first two actions, but not the latter two. This is a huge leap.

Step 3a: Configure the criteria for the second set of related actions

We’re looking at the result of the associated approval process here. Basically, if the approval does not happen and the request is rejected, this criteria will be met.

Step 3b: Add related action #1 (Update Child Cases) for the second decision point

I am once again updating child cases here. If the closure request is rejected, the child cases will be set to “On Hold.”

Step 4a: Configure the criteria for the third (and final) set of related actions

Here, we’re looking for an approval for the closure. That comes in the form of “Close Child Cases” being set to True. If that has happened, we’ll go ahead and trigger the related actions.

Step 4b: Add related action #1 (Close Child Cases) for the third decision point

Now that the parent case has been approved for closure, we can set all of the child cases to close, as well.

Step 4c: Add related action #2 (Assign Task to Case Owner) for the third decision point

Let’s create a task for some post-resolution analysis of what happened to prevent this from occurring again. Another huge enhancement is the ability to dynamically set this field to a relative user (in this case, the Case Owner) instead of hardcoding it as one specific user.

Also, note that I am setting the reason dynamically, as well. I am populating it with the parent’s reason. You cannot set the field dynamically in the same way with workflow rules.

Step 4d: Add related action #3 (Post to Chatter) for the third decision point

Another new feature. What is so great about this is that allow you to do the following with your post:

Post to a specific group
Include one or more users via mention
Include one or more topics

Let’s take a look at the overall process that I just created:

Evaluating a record multiple times

As you can see above, once a “TRUE” decision path is followed, an end is waiting just after the actions occur (note the “STOP” element). That would suggest that one set of actions can occur per record update. However, that’s not actually the case. Salesforce allows the process to iterate up to five times after the original execution.

Here’s a quick example I threw together to show how that works. Here is the process:

The actual example used is just for clarity. In it, we have three decision points and one corresponding action for each step:

Filter criteria for step 1: If subject = “1”, then change subject to “2”
Filter criteria for step 2: If subject = “2”, then change subject to “3”
Filter criteria for step 3: If subject = “3”, then change subject to “1”

The key to this example is the fact that “Allow process to evaluate a record multiple times in a single transaction?” is set to true (checked):

Because we have set it to true, the process will evaluate the same record up to five additional times. Here’s the result.

You can see that I made the change of Subject from “a” to “1” and it caused an initial update of Subject to “2” and then five subsequent updates.

There are some additional considerations you should keep in mind when working with Process Builder. These may change as Process Builder gets further built out:

In the Update a Record action, you can’t set a text field with a Formula within Process Builder (like you can with a workflow field update).
In the Update a Record action, you can set a text based on a Formula field on the same record or a lookup record. This makes the previous bullet point less of an issue.
You can you set only one schedule for future actions per decision point. Alternatively, you can set multiple time triggers within workflow rules today.

Filling your declarative development quiver

If you do have interest in using Process Builder, you will need to make some key decisions within your organization or for your client(s) to determine how to best approach declarative development moving forward. You have three tools that overlap (Workflow, Visual Workflow, and Process Builder). There is definitely not a one-size-fits-all answer to the question of “Which tool or tools should I use?” You will need to consider what workflows, flows, and processes already exist in your org, the likely direction in which you’re headed, and how you plan on managing these elements. There is nothing “built in” to automatically alert you to conflicts between the products of each tool and you’ll need to have a handle on how they potentially overlap.

Final words

All in all, I highly recommend taking a look at Process Builder. It is an excellent means to quickly build powerful solutions to deliver business process automation within Salesforce.com. Good luck building your next process!