Say Goodbye to Workflow and Hello to Process Builder

Learning Objectives

After completing this unit, you’ll be able to:
  • Explain the business value of Process Builder compared to Workflow.
  • Describe the overall process of converting workflow rules to processes.

New Company, New Org

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.



The examples described in this module include custom fields and email templates that don't exist in your Trailhead Playground. This module doesn't show you how to create those fields or templates, because our focus is on the concepts and best practices for migrating workflow rules. We recommend that you read along to understand the concepts, but don't try to follow the exercise steps in your playground. You apply your conceptual knowledge to complete the challenges at the end of each unit. Don't worry: you don't need to create any custom fields or email templates to complete any of the challenges.

Let’s Compare: Workflow vs. 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.


Because you can’t choose which workflow rule is evaluated first, choose one tool to automate everything for a given object. If you use both Workflow and Process Builder, you can’t reliably predict the results of a record change.

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, Flow Builder, 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.

Rule Name Criteria Actions
Escalate Based on Keywords in Subject or Description Evaluation Criteria: created or edited to subsequently meet criteria
Rule 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")
  • Field Update: Set Priority to Service Affecting
  • Field Update: Set Support Level to Tier 3
  • Field Update: Set Target Resolution Date to TODAY()

Time-Dependent: n/a

Follow Up When a Platinum Contract Case Closes Evaluation Criteria: created or edited to subsequently meet criteria
Rule Criteria:
  • (Case: Priority equals High) and
  • (Case: Closed equals True) and
  • (Case: Contract Type equals Platinum)
Immediate: n/a
7 Days After Case: Date/Time Closed:
  • Email Alert: Email a feedback request to the case contact
Notify Sales VP About Cases Filed for High-Value Accounts Evaluation Criteria: created

Rule Criteria: (Account: Top Account equals true)

  • Email Alert: Notify AE about cases for large accounts
  • Email Alert: Notify AE’s manager about cases for large accounts

Time-Dependent: n/a

Set Resolution Date for Basic Support Evaluation Criteria: created

Rule Criteria: (Case: Support Plan equals Basic)

  • Field Update: Set the Target Resolution Date to TODAY() + 30

Time-Dependent: n/a

Set Resolution Date for Premium Support Evaluation Criteria: created

Rule Criteria: (Case: Support Plan equals Premium)

  • Field Update: Set the Target Resolution Date to TODAY()

Time-Dependent: n/a

Set Resolution Date for Standard Support Evaluation Criteria: created

Rule Criteria: (Case: Support Plan equals Standard)

  • Field Update: Set the Target Resolution Date to TODAY() + 14

Time-Dependent: n/a

Only two of the six 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 possible. 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.



Build and test your processes in a sandbox environment. That way, you can identify any issues without affecting your production data.

  1. Map your rules’ criteria into process criteria. Consider whether to nest any criteria with invocable processes.
  2. Map your rules’ actions into process actions.
  3. 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 are just as good as a whiteboard or spreadsheet.