Start tracking your progress
Trailhead Home
Trailhead Home

Map Your Workflow Actions to Process Actions

Learning Objectives

After completing this unit, you’ll be able to:
  • Create reusable actions for Process Builder.
  • Describe best practices for converting workflow actions into process actions.
  • Create a plan for how to convert workflow actions into process actions.
Important

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.

Reusable Process Actions

One thing that a lot of admins miss from Workflow is building an action once and using it in many workflow rules. No one likes to waste time building the same thing again and again. While Process Builder doesn’t have reusable actions like Workflow does, it does have quick actions and invocable processes.

Quick Actions

Salesforce provides two action types that live under the umbrella term “Quick Actions”: global actions and object-specific actions.

Tip

Tip

Quick actions are the ultimate reusable action. They’re available in way more tools than just Process Builder. Here are some other features that use quick actions.

  • Flows
  • Page layout buttons and list views
  • Chatter publisher (global actions only)
  • Salesforce for Outlook (global actions only)

After you create the action and set the field on its layout, you can go to the detail page and set predefined field values. The predefined field values are the secret sauce that makes quick actions a viable solution for creating reusable process actions.

There are two main differences between global and object-specific actions.
  • Both types can create records, but only object-specific actions can update records.
  • Object-specific create actions create records that are automatically associated with related records. A record created by a global create action has no relationship with other records.

Since workflow actions are always associated with a specific object, let’s focus on object-specific actions. Here’s a quick rundown of how to convert your field update and task workflow actions into quick actions.

Workflow Action Quick Action Type Action Layout Predefined Field Values
Field Update Update a Record Remove all fields. Set the same values as the workflow action provided.

You can combine multiple field update actions into one quick action. To do so, set multiple predefined field values for the same action.

Task Create a Record Remove all fields. Set the same values as the workflow action provided.
Note

Note

  • Don’t use a quick action to update a field on a related record. Quick actions can update fields only on the specified record. For example, a Case-based quick action can’t update fields on the associated account.
  • If you’re using a quick action in another feature (like a page layout) and in Process Builder, make sure that the action layout includes at least one field.
  • When you configure a Create action, make sure that every required field either has a predefined field value set or is included in the action layout.

Assuming that all the appropriate fields have predefined field values, the action configuration in Process Builder is minimal. You select the appropriate quick action and choose a value for Related Record ID.

Configuring Related Record ID for a quick action

In create actions, Related Record ID tells the action which record to associate the new record with. In update actions, Related Record ID tells the action which record to update.

Invocable Processes

If you did the earlier unit on mapping criteria, you got a quick introduction to invocable processes. Basically, they’re modular processes that you can reference in one or more processes. One use case of invocable processes is for action reusability.

If you have actions that apply to multiple criteria nodes in one process—or across multiple processes:

  1. Create an invocable process. To do so, when you create the process set The process starts when to It’s invoked by another process.
  2. In the invocable process, add at least one criteria node. If you want the process to execute those actions every time, select No criteria–just execute the actions!
    Selecting "No criteria" for Criteria for Executing Actions
  3. In the invocable process, build the actions.
  4. In the appropriate processes, add a Processes action to the appropriate criteria nodes

Workflow Actions vs. Process Actions

For each workflow action that’s available, there are one or two corresponding process actions. Let’s see how field update, task, email alert, and flow trigger workflow actions convert into process actions, as well as what to think about before converting the actions.

Note

Note

This module doesn’t cover how to convert outbound messages. However, you can write an Apex class to replace the outbound message, then use it in an Apex process action.

Field Update Workflow Actions

The process action that corresponds most directly to the field update workflow action is Update Records. But first, consider a couple of things.
  • Do you have multiple field update workflow actions for the same object associated with the same criteria node? Combine them all into one process action.
  • Does this field update workflow action apply to multiple criteria nodes? Create an object-specific action and reference it by using a Quick Actions process action. Otherwise, use an Update Records process action.

Most of the settings on the field update workflow action are available in the process actions, but not all of them. You can re-create the functionality through other actions or settings in your process.

Field Update Action Setting Description Process Builder Setting
Re-evaluate Workflow Rules after Field Change (1) If the field update results in a change to the value of the field, Salesforce reevaluates all workflow rules on the object. Doing so triggers any workflow rules whose criteria are met. In the object node, expand the Advanced settings and select Yes.
Notify Assignee (2) Only available when updating the record owner. When selected, Salesforce sends an email to the new owner of the record. Re-create this functionality with an email alert.
Visual representation of how additional options in field updates correspond to settings in Process Builder

Task Workflow Actions

You’ve probably noticed that there’s no specific Task action in Process Builder. Unlike Workflow, Process Builder doesn’t limit the objects whose records you can create. Instead of an action specifically for creating tasks, use the Create a Record process action.

Before you configure your process to create a task, review your task actions.
  • Do any of your tasks tell your users to do something that Workflow can’t automate but Process Builder can automate? Remove the middleman and have the process automate that thing.

    For example, your workflow rule assigns a task for the account owner to create an SLA. Rather than re-create that task in Process Builder, cut out the middleman. Have the process create the SLA on behalf of the account owner.

  • Does this task apply to multiple criteria nodes? Create an object-specific action and use the Quick Actions process action. Otherwise, use a Create a Record process action.

Email Alert Workflow Actions

Now for something a little easier: email alerts. Email alerts are the only workflow action that you can reuse directly in Process Builder. Rather than looking at the guts of the email alert and configuring the same settings in Process Builder, call the email alert from the process.

Configuring an email alert action in Process Builder

Email vs. Chatter

However, email alerts aren’t the only process action that sends notifications. Post to Chatter is also available. To determine which action to use, use these three points of comparison: what the notification says (message), who it’s sent to (recipients), and who else can see the message (publicity).

Message
You can write the same message in a Chatter message as you can in your email templates. However, rich text isn’t supported.
If rich text is necessary for your notification, use an email alert.
Recipients
In an email alert, you can select from a variety of users, email fields, or groups of people. For example, if the email alert is associated with Case, you can select the account owner, the case team, the case creator, an email field on the case, the case owner, a public group, a related contact, the owner of a related lead or contact, a related user, a role, a role and its subordinates, or a specific user.
In a Post to Chatter action, you can post to a few different feeds.
  • The record that started the process.
  • A user—One who’s related to the record or a specific user.
  • A Chatter group—Public or private, but not private with customers.
You can mention any user, as long as you can reference the user ID from the field picker. For example, you can select a case’s account’s owner’s manager. Or that person’s manager. Or the manager’s manager’s manager. Since roles, public groups, and teams don’t have feeds and aren’t accessible from the field picker, you can’t notify them with a Chatter post.
Recipient Type Supported In
Email Alert Post to Chatter
Specific user Yes Yes
Related user

Yes

(limited)

Yes

(unlimited)

Related record owner, Account owner Yes Yes
Role, Role and Subordinates Yes No
Creator Yes Yes
Public group Yes No
Object team Yes No
Tip

Tip

To notify a customer, use an email alert.

Consider who you want to receive the message, and use that to determine which action works for your requirements. For example, to send the message to a specific public group or the case team, use email alerts. To send the message to the case owner’s manager, use Chatter.

Publicity
One last point of comparison for these notifications is how public the notification is. Emails are sent on a one-on-one basis. With Chatter posts, the publicity of the message depends on which feed you post to.
  • Email—Only the recipient sees the message.
  • Post to a user’s feed—Anyone can see the message when they visit that user’s page.
  • Post to a record’s feed—Anyone with access to the record can see the message.
  • Post to a Chatter group (public)—Anyone can see the message when they visit that Chatter group.
  • Post to a Chatter group (private)—Only members of the group can see the message.
Consider how private the message should be, and use that to determine which action works for your requirements. For example, if you want only the recipient to see the message, use an email alert. If you want anyone who cares about the record to see the message, post to the record’s Chatter feed.

Flow Trigger Workflow Action

Are you converting a workflow rule that includes a flow trigger workflow action? Flow triggers aren’t as easy to convert as email alerts are, but they’re a close second. To configure a Flows action in Process Builder, you call the same flow and provide the same values to the flow’s variables.

Comparison of configuring a flow trigger workflow action vs. a Flows process action
All right, it’s cool that so much maps directly from the flow trigger workflow action to the Flows process action. But what’s different?
  • Process Builder’s equivalent option for {!this} is Select the Object record that started your process.
  • Process Builder doesn’t have an equivalent option for {!old}.
Process Builder doesn’t have an equivalent setting to Administrators run the latest flow version. We recommend building and testing your processes in a sandbox.
Note

Note

Flow trigger workflow actions were previously available as a pilot program, which is now closed. If you’ve already enabled the pilot in your org, you can continue to create and edit flow trigger workflow actions. We recommend using the Flows process action instead.

Time Triggers

If you’ve spent any time building workflow rules or processes, you know that you can customize when an action gets executed. Some of the terminology varies between tools, but the functionality is the same. The steps for creating a time trigger are largely the same as the steps for creating a schedule.

Workflow Process Builder
Immediate Actions Immediate Actions
Time-Dependent Actions Scheduled Actions
Time Trigger Schedule

When you create a time trigger or schedule, you configure an offset (such as 30 Days After) from a date. In Process Builder, you can reference any date or date/time field (1) or use the “from now” construction (2), which corresponds with the Rule Trigger Date option in Workflow.

Configuring a schedule in Process Builder
Note

Note

Case-based time triggers include some options that don’t exist in Process Builder, such as Case: Entitlement Process Start Time. The option doesn’t exist in Process Builder because it isn’t an actual field. We recommend creating a formula field to calculate that option and referencing the formula field in your process schedule.

But wait, once you convert time-based workflow actions to scheduled process actions, how do you monitor them? In Setup, the Flows page includes a section called Paused and Waiting Interviews. When a process schedules actions to occur, you can track them here. To understand how to translate this page for processes, see Monitor Your Processes’ Pending Scheduled Actions in the Salesforce Help.

Paused and Waiting Interviews list on the Flows page in Setup

Comparison Summary

This table summarizes how to convert workflow components to Process Builder components, as well as what to consider before converting them.

Workflow Component Process Builder Equivalent Things to Consider
Field Update

Update Records

Quick Action

The process actions aren’t limited to updating one field. If you have multiple field updates in the same action group, consider lumping them together into a single process action.
Task

Create a Record

Quick Action

Process Builder lets you automate more than Workflow does. Evaluate your tasks, and identify whether any of your tasks are for things that a process can do automatically.

For example, a workflow rule creates a task for the account owner to submit a contract for approval. When converting that task into Process Builder, you use the Submit for Approval action to eliminate that task for the account owner.

Email Alert Email Alerts You can also notify stakeholders via Chatter with the Post to Chatter action.
Flow Trigger Flows n/a
Time Trigger Schedule n/a

Map Your Workflow Actions into Process Actions

Now let’s apply what we’ve learned about process actions to the case workflow rules. Just like you did in the previous unit for criteria, you create a game plan for the process’ actions.

Here are the workflow actions that correspond to each workflow rule. We’re using the criteria names because they’re shorter.

Criteria Name Workflow Actions
Immediate Time Trigger Time-Dependent
Top Account Email Alert: Notify AE about cases for large accounts

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

n/a n/a
Basic Support Field Update: Set the Target Resolution Date to TODAY() + 30 n/a n/a
Premium Support Field Update: Set the Target Resolution Date to TODAY() n/a n/a
Standard Support Field Update: Set the Target Resolution Date to TODAY() + 14 n/a n/a
Platinum Contract Case Closes n/a 7 Days After Case: Date/Time Closed Email Alert: Email a feedback request to the case contact
Escalation Keywords Field Update: Set Priority to Service Affecting

Field Update: Set Support Level Tier 3

Field Update: Set Target Resolution Date to TODAY()

n/a n/a

Let’s target each action by type. First up: field updates.

Map the Field Update Actions

Now let’s apply what we’ve learned about process actions to the case workflow rules. Just like you did in the previous unit for criteria, you’ll create a game plan for the process’ actions.

Here are the workflow actions that correspond to each workflow rule. We’re using the criteria names because they’re shorter.

Criteria Name Field Value
Basic Support Target Resolution Date TODAY() + 30
Premium Support Target Resolution Date TODAY()
Standard Support Target Resolution Date TODAY() + 14
Escalation Keywords Priority Service Affecting
Support Level Tier 3
Target Resolution Date TODAY()

Two of the criteria nodes update the same field (Target Resolution Date) with the same value (TODAY()). That’s definitely a candidate for a reusable action. You can create an object-specific action on Case that sets Target Resolution Date to TODAY(), then reference that quick action in both the Premium Support and Escalated Keywords criteria nodes.

Also, the Escalation Keywords criteria node updates multiple fields, so you can combine all of those into one action. However, you’re converting one of those field updates into a quick action, so combine the remaining two into one action.

Criteria Name Action Field Value
Basic Support Update Records Target Resolution Date TODAY() + 30
Premium Support Quick Action Target Resolution Date TODAY()
Standard Support Update Records Target Resolution Date TODAY() + 14
Escalation Keywords Update Records Priority Service Affecting
Update Records Support Level Tier 3
Quick Action Target Resolution Date TODAY()

Your collection of workflow rules only has two action types, so let’s tackle the remaining one now: email alerts.

Map the Email Alert Actions

The whole reason you’re converting these workflow rules into a process is to notify more with Chatter than with email, so let’s consider which email alerts should be converted into Chatter posts.

Criteria Name Email Alert Name Recipients Rich Text in Message Publicity
High-Value Account Notify AE about cases for large accounts Account owner No Doesn’t matter
Notify AE’s manager about cases for large accounts Role: Division lead or Account owner’s manager No Doesn’t matter
Platinum Contract Case Closes Email a feedback request to the case contact Contact email on case Yes 1:1 with customer

You can convert the first two to Chatter posts, because the recipients are accessible from the Post to Chatter action, rich text isn’t important to the message, and the message doesn’t need to be private. In fact, since you can mention multiple people in Chatter posts, you only need to use one action. To keep everyone who cares about the case apprised, post to the case’s Chatter feed.

However, to send a feedback request to the case contact, you continue to use an email alert. In Process Builder, only email alerts can be sent to customers.

Criteria Name Action Configuration Notes
Top Account Post to Chatter Post to this record. Use the email template for “Notify AE about cases for large accounts” and “Notify AE’s manager about cases for large accounts” for full message. Mention account owner and account owner’s manager.
Platinum Contract Case Closes Email Alert Reference “Email a feedback request to the case contact” email alert

In the last unit, you decided to use an invocable process for all of the create-only criteria nodes. That invocable process will never run if you don’t add an action for it. Let’s account for a Processes action in the plan.

Map the Processes Action

To configure a Processes process action, identify the process (New Cases) and which record to send to that process. In this instance, the invocable process should evaluate the same record as the top-level process.

Criteria Name Action Configuration Notes
New Case Process Process: New Cases

Record: The case that started this process

Map the Time Trigger

Let’s quickly convert the time trigger into a process schedule. Date/Time Closed is a field on the Case object, so the configuration is really similar. 7 Days After Case: Date/Time Closed becomes 7 Days After Closed Date.

All Together Now: The Final Action Plan

Finally, let’s combine the plans for the field update actions, email alert actions, and time trigger into one plan for all the process actions.

Criteria Name Actions
Immediate Schedule Scheduled
Top Account Post to Chatter: Notify AE and manager about cases for large accounts

(Post to record, use email template from original email alerts for message, mention account owner and account owner’s manager.)

n/a n/a
Basic Support Update Records: Set Target Resolution Date to TODAY() + 30 n/a n/a
Premium Support Quick Action: Set Target Resolution Date to TODAY() n/a n/a
Standard Support Update Records: Set Target Resolution Date to TODAY() + 14 n/a n/a
Platinum Contract Case Closes n/a 7 Days After Close Date Email Alert: Email a feedback request to the case contact
Escalation Keywords Update Records: Set Priority to Service Affecting and Support Level to Tier 3

Quick Action: Set Target Resolution Date to TODAY()

n/a n/a
New Case Process: New Case, include reference to the case that started this process n/a n/a

Implement the Actions in Your Process

Now that you’ve got a plan for every action in your Case workflow rules, let’s add them to the process. This part builds on the previous unit, so we recommend that you finish that first.

Our plan lists every action, based on which criteria they’re associated with. The first four belong to the invocable process, and the last three belong to the top-level process.

Before you dive back into the processes, let’s take care of everything you need outside of Process Builder. In the plan, the only component you need that isn’t already created (that is, email alerts from the workflow rules) and is created outside of Process Builder is the quick action.

Create the Quick Action

To review, the quick action updates Target Resolution Date to today’s date. Use a predefined field value to always set Target Resolution Date to today.

  1. From the object management settings for cases, go to Buttons, Links, and Actions, and click New Action.
  2. Configure the action’s properties.
    1. For Action Type, select Update a Record.
    2. For Label, enter Set Target Resolution Date to Today.
    3. Save the action.
  3. Configure the action layout.
    1. Remove all the fields from the action layout.
    2. Save the layout.
    3. In the dialog that appears, click OK.
      Although Status is a required field, it’s not necessary for an update action.
  4. Set a predefined value for Target Resolution Date.
    1. In Predefined Field Values, click New.
    2. For Field Name, select Target Resolution Date.
    3. In the formula editor, enter TODAY().
    4. Save the predefined value.

Now let’s build the process actions. First, add actions to the invocable process.

Actions in the Invocable Process

Return to Process Builder, and open the New Cases process.

Top Account: Post to Chatter

For the Top Account criteria node:

  1. Click Add Action.
  2. For Action Type, select Post to Chatter.
  3. Give the action a name.
  4. For Post To, select This Record.
  5. For Message:
    1. Paste the content of the email template that the “Notify AE about cases for large accounts” email alert references.
    2. Mention the account owner.
      1. Enter @[], and place your cursor inside the brackets.
      2. Click Merge Field.
      3. Click Account ID > to access the associated account’s fields.
      4. Enter Owner, select Owner ID, then click Choose.
    3. Mention the account owner’s manager.
      1. Enter @[] again, and place your cursor inside the brackets.
      2. Click Merge Field.
      3. Click Account ID > to access the associated account’s fields.
      4. Click Owner ID > to access the associated user’s fields.
      5. Enter Manager, select Manager ID, then click Choose.
    Mentions of account owner and account owner’s manager in Chatter post message
  6. Save the action.

Basic Support: Update Actions

Add an Update Records action to the Basic Support criteria node.

  1. Click Add Action.
  2. For Action Type, select Update Records.
  3. Give the action a name.
  4. For Record Type, select the Case that started your process.
  5. Set the new field values.
    1. For Field, select Target Resolution Date.
    2. For Type, select Formula.
    3. Click Build a Formula.
    4. In the formula editor, enter TODAY() + 30.
    5. Click Use this formula.
    Final configuration of updated field value
  6. Save the action.

Premium Support: Quick Action

For the Premium Support criteria node:

  1. Click Add Action.
  2. For Action Type, select Quick Actions.
  3. Give the action a name.
  4. Select the quick action.
    1. Filter search by object.
    2. Select Case.
    3. Select the quick action that you created: Set Target Resolution Date to Today.
  5. Set field values for the action. Because you want the quick action to update the case that started the process, set Related Record ID to this case’s ID.
    1. For Type, select Field Reference.
    2. For Value, click Find a field…, enter Case, select Case ID, and click Choose.
    Final configuration of quick action
  6. Save the action.

Standard Support: Update Records

For the Standard Support criteria node:

  1. Click Add Action.
  2. For Action Type, select Update Records.
  3. Give the action a name.
  4. For Record Type, select the Case that started your process.
  5. Set the new field values.
    1. For Field, select Target Resolution Date.
    2. For Type, select Formula.
    3. Click Build a Formula.
    4. In the formula editor, enter TODAY() + 14.
    5. Click Use this formula.
  6. Save the action.
View of all actions in the invocable process

One last thing before you move on to the top-level process. Remember how you planned to call this invocable process from the top-level process? You can do that only if the invocable process is active.

In the button bar, click Activate, then click Confirm.

Actions in the Top-Level Process

Now let’s build the actions for the top-level process. Click View All Processes, and open the Case Management process.

Escalation Keywords: Update Records

For the Escalation Keywords criteria node:

  1. Click Add Action.
  2. For Action Type, select Update Records.
  3. Give the action a name.
  4. For Record Type, select the Case that started your process.
  5. Set the new field values.
    Field Type Value
    Priority Picklist High
    Support Level Picklist Tier 3
  6. Save the action.

Escalation Keywords: Update Records

These steps are exactly the same as what you did for the Premium Support criteria node in the invocable process. For the Escalation Keywords criteria node:

  1. Click Add Action.
  2. For Action Type, select Quick Actions.
  3. Give the action a name.
  4. Select the quick action.
    1. Filter search by object.
    2. Select Case.
    3. Select the quick action that you created: Set Target Resolution Date to Today.
  5. Set field values for the action. Because you want the quick action to update the case that started the process, set Related Record ID to this case’s ID.
    1. For Type, select Field Reference.
    2. For Value, click Find a field…, enter Case, select Case ID, and click Choose.
    Final configuration of quick action
  6. Save the action.

Platinum Contract Case Closes: Schedule

Add a schedule to the Platinum Contract Case Closes criteria node so that actions occur 7 days after the case closes.

  1. Click Set Schedule.
  2. In the first field, enter 7.
  3. Leave Days and After selected.
  4. In the final field, select Closed Date.
  5. Save the schedule.

Platinum Contract Case Closes: Email Alerts

For the Platinum Contract Case Closes criteria node:

  1. Under the schedule you created (7 Days After ClosedDate), click Add Action.
  2. For Action Type, select Email Alerts.
  3. Give the action a name.
  4. For Email Alert, select the email alert that you used in the original workflow rule: Case_Request_feedback_from_contact.
  5. Save the action.

New Case: Processes

For the New Case criteria node:

  1. Click Add Action.
  2. For Action Type, select Processes.
  3. Give the action a name.
  4. For Process, select the invocable process that you activated: New Cases.
  5. Set a value for the process variable.
    You want the invocable process to evaluate the case that started the Case Management process, so use Value to select that ID.
    1. For Value, click Find a field….
    2. Select the Case that started your process.
    3. Click Confirm.
  6. Save the action.
Final view of actions in top-level process

Way to go! You’ve successfully converted the case workflow rules into criteria nodes and actions in one top-level process and one invocable process. Now for the last step: finalizing the order of the process criteria.

Resources

Lightning bolt icon used to indicate that the content is for Lightning Experience

Remember, this module is meant for Lightning Experience. When you launch your hands-on org, switch to Lightning Experience to complete this challenge.

retargeting