Say Goodbye to Workflow and Hello to Process Builder

Salesforce has two different desktop user interfaces: Lightning Experience and
Salesforce Classic. This module is designed for Lightning Experience.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

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.

Important

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.

Tip

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

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.

Tip

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

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.