Say Goodbye to Workflow and Hello to Process Builder
You’ve been working at Acme Wireless for a few months now. As you familiarize yourself with the inner workings of your new org, you keep mental notes of areas for improvement. Some of those areas you can address with quick fixes.
Others are implementations of solutions that aren’t necessarily the best practice for that problem. But the implementations work so there’s no burning need to fix them. It’s hard enough to keep apprised of newfangled features (hello, 1,200 pages of release notes every year), much less to actually implement those features. You don’t always have the time. Or even if you do have the time, the benefits aren’t enough to warrant it.
One such area for improvement: the large number of workflow rules used to automate everything rather than Process Builder.
What’s the big deal? #AwesomeAdmin, why spend your time converting automation from a tool that you know to a tool that you don’t know?
- Process Builder lets you automate more things.
- Process Builder includes more flexible actions compared with the corresponding workflow actions. The Create a Record process action, for example, lets you create any record instead of just tasks. Also, the Update Records process action (which corresponds with the field update workflow action) lets you update any related record, while the field update workflow action lets you update only the record or its parent.
- Process Builder also includes brand new actions that aren’t available in Workflow—such as Post to Chatter and Submit for Approval.
- Process Builder lets you control the order of your criteria.
- In Workflow, there’s no way for you to determine which order your workflow rules run in. So there’s always a risk of one rule overwriting what another did. In Process Builder, you determine the exact evaluation order of your process’ criteria. In turn, within a given process criteria, you determine the order of its actions.
- Process Builder lets you access fields on every related record.
- In Workflow, you can reference fields on the record’s parent. Process Builder, on the other hand, lets you access the fields on any related record, no matter how far away that record is. You can reference fields on a parent record, grandparent record, or great-great-great-grandparent record twice removed.
- Process Builder is the future.
- We’re no longer enhancing Workflow. We still support your use of workflow rules, and will continue to do so. But all new functionality for the workflow use case will come through Process Builder. If you want to use the shiny new functionality, migrate your automation to Process Builder.
Now you have all the information you need to decide between Workflow and Process Builder for future projects.
New Business Requirements
Change is a constant, in life and in your work as a Salesforce admin. So you’re not that surprised when you receive this email from the VP of customer service.
- A few months ago, we (or rather, your predecessor) rolled Chatter out to the company. As the executive sponsor, I’m jazzed to see adoption rising! But we’ve got some ways to go before we hit our target metrics. My team identified a possible way to push the needle even further, so I have a simple request.
- The support team receives tons of emails about their cases from Salesforce automatically. Can you change the implementation so that the team is notified via Chatter instead of email?
First, take a moment to chuckle. There’s no such thing as a simple request.
But nonetheless, it’s time to investigate the best way to change your org’s case management system. Three items in your admin toolkit let you automatically create Chatter posts: Apex triggers, Cloud Flow Designer, and Process Builder. Of those tools, Process Builder is the simplest. So you plan to migrate the Case-based workflow rules that send emails into processes with Process Builder.
Let’s take a second to review the existing Case workflow rules.
|Escalate Based on Keywords in Subject or Description||Evaluation Criteria: created or edited to
subsequently meet criteria
Contains(LOWER( Subject ),"urgent") || Contains(LOWER( Subject ),"password") || Contains(LOWER( Subject ),"down") || Contains(LOWER( Subject ),"emergency") || Contains(LOWER( Subject ),"internal server error") || Contains(LOWER( Description ),"urgent") || Contains(LOWER( Description ),"password") || Contains(LOWER( Description ),"down") || Contains(LOWER( Description ),"emergency") || Contains(LOWER( Description ),"internal server error")
|Follow Up When a Platinum Contract Case Closes||Evaluation Criteria: created or edited to
subsequently meet criteria
7 Days After Case: Date/Time Closed:
|Notify Sales VP About Cases Filed for High-Value Accounts||Evaluation Criteria: created
Rule Criteria: (Account: Top Account equals true)
|Set Resolution Date for Basic Support||Evaluation Criteria: created
Rule Criteria: (Case: Support Plan equals Basic)
|Set Resolution Date for Premium Support||Evaluation Criteria: created
Rule Criteria: (Case: Support Plan equals Premium)
|Set Resolution Date for Standard Support||Evaluation Criteria: created
Rule Criteria: (Case: Support Plan equals Standard)
Only two of the five workflow rules include email alert actions. However, it’s best practice to avoid mixing processes (from Process Builder) with workflow rules for a given object. Otherwise, you can’t guarantee what order the processes and workflow rules are evaluated in. If you want to replace one case workflow rule with a process, we recommend migrating every case workflow rule to Process Builder.
Convert Your Workflow Rules into a Process
The cost of new features is exacerbated when those features don’t have automatic migration options. We know: the idea of clicking a button to convert your workflow rules to Process Builder sounds super awesome. Unfortunately, workflow rules are different enough from processes to make that impossible. So we’re going to give you the next best thing: a module to walk you through the migration process.
It’s a bit meta, but this is the process to move away from Workflow and toward Process Builder. We cover each of these steps throughout this module.
- Map your rules’ criteria into process criteria. Consider whether to nest any criteria with invocable processes.
- Map your rules’ actions into process actions.
- Determine the optimal order of your criteria nodes.
We take each step in three parts: discussing what to consider during that step, drafting a plan for that step, and then implementing that plan in Process Builder. Throughout this module, we use tables to represent the plan. But you can use whatever planning tool you prefer. Pen and paper is just as good as a whiteboard or spreadsheet.