You may have heard, Process Builder is an #AwesomeAdmin’s Swiss Army Knife. Why, you ask? Process builder allows Administrators the ability to chain individual process events together, eliminating the need for the multiple workflow rules we’re all used to, with immediate and scheduled actions, all in one place. In some cases, process builder can eliminate the need to write custom code to automate processes. Administrators can make enhancements to automated processes with point-and-click efficiency, making them less dependent on their developer counterparts, to implement more out-of-the-box solutions. We can stop using apex code to automate simple tasks, which means no test coverage needed. Hooray!

With Process Builder, you can:

• Create a record
• Update any related record, not just the record or its parent
• Post to chatter on the record, to a chatter group or user
• Use a quick action to create or update a record or log a call
• Submit a record for approval
• Autolaunch a visual workflow
• Send an email
• Call apex code

Similar to workflow rules, you can identify these actions to occur immediately or schedule them to occur, like time based workflow actions.

There are some limitations with process builder that you should be aware of. Visit Help & Training. To understand how to troubleshoot process builder, read the article in Hellp & Training.

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

• Process builder is a great tool for administrators, allowing you to automate/consolidate processes rather than work through/troubleshoot a long list of workflow rules. Also, it eliminates the need to touch apex code to automate simple tasks. Less code, more out-of-the-box Salesforce declarative solutions.
• 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 noting the data stored in a custom field, providing the purpose of a process builder, etc.

 

Business Use Case: Addison Dogster is a system administrator at Universal Containers. Customer service reps at Universal Containers may have cases in which there is a parent case and several child cases. If a parent case is closed, all related child cases should also be closed.  A chatter post should be added to the parent case indicating its closure. 3 days after the case’s close date, a a follow up task should be created and assigned to the case owner to follow up with the customer. Additionally, when a case is updated, the Last Case Update field should be updated on the account.

Solution: Addison is able to solve this declaratively by creating a custom checkbox field on the Case object to indicate whether a case has child cases, a custom date/time field on the Account object to capture the Last Case Update, enabled the chatter feed on the Cases object and create a process builder to update the child case processing field on a parent case, close child cases when a parent case is closed, post to the parent case record, create a follow up task 3 days after the case closed date and update the Last Case Update field on the related account record when a case is updated.

Note: For this use case, we assume chatter is already configured for the Cases object. We will not be covering how to configure those in this blog post.

Quick Steps:

This assumes that you have already created a Sales News chatter group and an opportunity approval process for Finance approval in your Salesforce org.

1.Create a custom checkbox field on the Case object to indicate whether a case has child cases. This field is called Child Case. The FLS should be set to be visible and editable by the System Administrator and visible to the Customer Service Rep so the process can write to the field. However, since this is a processing field, this field does not need to be added to any Case page layout.

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what this custom field is used for.
• Set the FLS (field level security) for each profile. Only make the field visible and visible/editable for the profiles that need it. Do not just click the “Next” button when you are on the screen.
• Only add the new field to the necessary page layout(s).

 

2. Create a custom date/time field on the Account object (Customize | Accounts | Fields) called Last Case Update. The FLS should be set to be visible and editable by the System Administrator and visible to the Customer Service Rep. Edit the Account page layout(s) to move the field to the desired location on the page. Also, this field should be marked as Read Only on the page layout so users can’t just go and modify the field.

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what this custom field is used for.
• Set the FLS (field level security) for each profile. Only make the field visible and visible/editable for the profiles that need it. Do not just click the “Next” button when you are on the screen.
• Only add the new field to the necessary page layout(s).

3. Create a process builder (Create | Workflows & Approvals | Process Builder). Click on the New button.

A. Create a new process. Give it a name, description and click on the “Save” button.

B. Specify Case as the object, select “when a record is created or edited” and click on the “Save” button.

C. For the first node criteria, provide a criteria name. We’re going to call it “Child Case”. Specify as the criteria for executing actions as “Conditions are met”. We want this criteria to execute if the Parent Case ID field has a value (i.e Parent Case ID is null boolean false)

Click within the Field box in the Set Conditions box. Start typing “Parent”. As you start typing, you will notice that the system will start filtering the fields.

Select “Parent Case ID” as the case field and click on the “Choose” button.

Select “Is null” as the operator and “False” as the value. This means that the Parent Case field is not blank. I know, the statement “parent case is null” is false, which means it is not blank, it has a value. Then, for conditions, leave it as is, set to “All of the conditions are met (AND).

Under Advanced, check “Yes” so that the actions will only execute when specific changes are made to the record. Click on the “Save” button.

This is the end result…Click the “Save” button.

D. Now, we want to update the parent case and check the child case processing checkbox. We will create an immediate action, select “Update Records” as the action type. Then, click in the “Record Type” field, select “Select a record related to the Case”. Then in the picklist field, start typing “parent” and select the “Parent Case ID”. Click the “Choose” button.

In the Record field, you should have [Case].Parent Case ID.

Leave the Criteria for Updating Records to “No criteria – just update the records!”. Then set the new field values to Child Case to true.

Here is your end result…Click the “Save” button.

E. We’re going to now set up our second criteria node – Parent case is closed. We will leave the criteria for executing actions as “Conditions are met.” We want this to execute when the case’s status is closed and the parent case ID field is blank or does not have a value.

For the first condition, we will select the Status field and set the picklist to “Closed. For the second condition, we will select the ParentId field, set the operator to “is null” and the value to “True.” For the third condition, we will select the Child Case field, set “equals boolean to true.” Then, for conditions, leave it as is, set to “All of the conditions are met (AND).

Under Advanced, check “Yes” so that the actions will only execute when specific changes are made to the record. Click on the “Save” button.

This is the end result…

F. For the first immediate action, we want to close the related child cases associated to the parent case. For the Action Type, select “update records.”Click on the record type box, choose “Select a record related to the Case”.

We want to update the associated cases, so we’re going to start typing “cases” and select “Cases” as an option. Click on the “Choose” button.

What appears in the Record Type field is [Case].Cases.

For the Criteria for Updating Records, leave it defaulted to “No criteria—just update the records!”

In the Field box, select Status and choose “Closed” as the picklist value. Click the “Save” button.

The end result is this…

G. For the second immediate action, we want to post a message to the parent case’s chatter feed. For Action Type, select “Post to Chatter.” Provide an action name. For the Post To picklist, select “This Record.” Lastly, in the Message text box, we will type the following where we are selecting the merge field Account Name”:

This case for {![Case].Account.Name} is now closed along with any child cases.

Here is the end result…Click the “Save” button.

H. To satisfy the requirement for following up with the customer 3 days after the case’s closed date, we will need to establish a scheduled action. We have a few options here, we can either schedule it for X hours or days from now or we can select X number of days/hours, either after or before, a specific date field on the Case object. In our case, we want to set this to 3 days after the case’s closed date. The end result looks like this…

Next, we need to create that follow up task. For Action Type, we will select “Create a Record.”. For record type, locate “Task”. Then we will set specific fields to be set when creating the task, due date, assigned to, priority, status subject, relate it to the case and contact.

By default, you get the Assigned To, Priority and Status fields. You will need to add more by clicking on the Add Row button.

For the Due Date Only, we will set it to today’s date using a formula with the syntax “Today().”

To assign the task to the case owner, for Assigned to ID, we will use “Reference” as a type and select the OwnerId.

To relate the task to case, you need to select “Related to ID” in the field, select “Reference” as the type and select Case ID as the value.

To associate the task to the case’s contact, select “Name ID” as your field, select “Reference” as the type and select “Contact ID” as the value.

Click the “Save” button once you’ve set all the fields on the task.

The end result looks like this…

I. Lastly, let’s set up the last criteria note – Case Update. We want this to run when a case updates – using the case’s last modified date. In this case, for the criteria for executing actions, we will select “Formula evaluates to true.”

In the Build Formula text box, enter this formula: ISCHANGED([Case].LastModifiedDate)

Under Advanced, check “Yes” so that the actions will only execute when specific changes are made to the record. Click on the “Save” button.

This is the end result…

J. For the second immediate action, we want to update the last case update field on the associated account record with the case’s last modified date. For Action Type, we will select “Update Records.” For the action name, we use “Update the Last Case Update on the Account.”

Click on the record type box, choose “Select a record related to the Case.” Start typing “Account” and select the Account ID field. Click on the “Choose” button.

So, the end result in the Record field is [Case].Account ID.

Leave the criteria to No criteria—just update the records!.

In the field box, type “Last Case Update”. Here, we will want to reference the value of the case’s last modified date, so we will select “Reference” as the type and then select “Last Modified Date in the value field.

The end result looks like this…Don’t forget to click on the “Save” button.

K. Click the Activate button in the upper right hand corner. You will see the pop up below. Click the “Ok” button.

That’s it. Congrats, you’ve implemented the solution!

Now, before you deploy the changes to Production, you need to test your configuration changes.

1. Create a parent case associated to a contact. Then proceed to create at least one child case.
2. Update the parent case’s status to “Closed”
3. Confirm the following:
   • A chatter post is added to the parent case record.:

This case for {[Case].Account Name}  is now closed along with any child cases.

• The status of the child case(s) is/are closed.
• The last case update field on the account is updated with the case’s last modified date.
• A task is created 3 days after the case’s closed date associated to the case owner and case’s contact along with the other task information from the process builder.

Deployment Notes/Tips:

• The custom fields and process builder can be deployed to Production in a change set.
• The field level security for the custom account field will need to be manually updated post deployment. I would caution against adding the related profiles in the changeset for deployment as the results of deploying a profile are not reliable. If you have a tool like Snapshot by Dreamfactory, you can use the tool to deploy field permissions.
• You will find the process builder component in a change set under the Flow Definition component type.
• Activate the process builder after it is deployed in Production as process builders are deployed as inactive.