Identify the capabilities of the declarative process automation features.
These are technical notes I compiled while studying using Focus on Force, a company that provides Salesforce training and certification prep services.
After studying this topic, you should be able to:
- Identify the major capabilities of Workflow Rules, Approval Processes, Process Builder, and Flows
- Describe when to use each automation tool to meet a business requirement
Table of Contents
- Intro & Videos
- Even Administrators need some additional permissions to use “Lightning Email Templates”: Need to grant admins permission to “Access Drag-and-Drop Content Builder,” “Manage Public Lightning Email Templates”
- Sending Outbound Messages is a legitimate use case for Workflow Rules - Outbound messages send messages in a very specific format to a SOAP endpoint
- This is one way of setting up a SOAP message declaratively, without a programmer
- Since the 2020 releases, Salesforce has been messaging that Flows are the tool of choice for declarative automation. In W22, Salesforce said Process Builder and Workflow Rules are on the roadmap for deletion.
- Flows can create and delete records, even ones not directly related to the record that started the Flow
- Autolaunched Flows happen as a result of one of four items:
- Explicitly called from a process/button/etc
- Triggered when a record is created, updated, or deleted
- Scheduled to run once, daily, or weekly
- Triggered upon receiving a platform event message
- Flows are the only declarative tool that can handle processing logic before the deletion of a record
- By default, Apex runs in system context, but flows can run in either user context or system context
- Running a Flow in Flow Builder impacts production data - record inserts, deletes, etc, will execute
- In “Process Automation Settings,” note there is a checkbox (unchecked by default): “Let admins debug flows as other users”
- Process Automation Features
- 4 declarative tools: Flow Builder, Process Builder, Workflow and Approvals
- Workflow: single if/then where an action is performed if a defined criteria is met
- Approvals: single if/then statement manner and used to automate approval processes
- Process Builder: perform actions as result of multiple if/then statements
- Flow Builder: complex requirements and more advanced functionality
- Email Alerts and Email Templates
- Email alerts: can be associated with processes, flows, workflow rules, approval processes, entitlement processes
- Email template: selected while defining and email alert, both Classic and Lightning email templates can be selected
- Merge fields: email templates support inserting merge fields that reference specific information based on the record that triggers the email alert
- 4 declarative tools: Flow Builder, Process Builder, Workflow and Approvals
- Workflow
- Field updates, send text or html emails, create and assign tasks, send outbound messages (send data to a web service endpoint)
- Approvals
Reference FoF Slides
- Process Builder
- Can publish a platform event message
- Can be configured to start when it receives a platform event message, in that case called an event process
- Flow Builder
- Recommended as a replacement for Process Builder and Workflow Rules whenever feasible
- Especially recommended in automations that require before-save operations
- Flows can be used to publish platform events
- Platform Event-Triggered Flows are also available, which subscribe to a platform event and start when the event message is received
- Screen Flows require a user interface for users to interact with
- Autolaunched Flows contain pure logic and runs in the background when invoked
- Screen Flows
- Flows can be made into templates and templates can be cloned to create custom business processes
- Aura and Lightning Web components can be added to flow screens
- Section Component can be used to create flow screens with multi-column layouts and header text
- Screen Flow Usage Reports contain runtime details about an org’s screen flows - useful for determining how to improve screen flow efficiency for users
- Autolaunched Flows
- Four types of autolaunched flows:
- No Trigger: explicitly called from a process, button, etc
- Record Triggered: triggered when a record is created, updated, or deleted
- Schedule Triggered: can be scheduled to run once, daily, or weekly
- Platform Event Triggered: triggered upon receiving a platform event message
- Four types of autolaunched flows:
- Autolaunched: Record-Triggered Flows
- Record-Triggered flows provide a Trigger Order property for specifying when the current flow should run when there are multiple flows for the same object and trigger type (before-save, after-save)
- Scheduled Paths can be defined to execute a part of the flow at a dynamically scheduled time
- Scheduled time can be based on when the record is created/updated, or on a field value on the record
- Time-Based Workflow page in Setup can be used to monitor the scheduled paths that are queued to run
- Asynchronous Paths in a record-triggered flow can update external objects, perform a callout to an external system, execute a set of actions that do not need to be completed in the current transaction, etc
- Flow Trigger Explorer
- Tool for viewing record-triggered flows that are associated with a specified object and identifying how or when they are triggered based on a record change
- Accessible from start element of a record-triggered flow, Flows page in Setup, or Flow Triggers tab in the Object Manager
- Using the Edit Order button, Flow Trigger Explorer allows sorting the execution order by dragging and dropping the flows
- Tool for viewing record-triggered flows that are associated with a specified object and identifying how or when they are triggered based on a record change
- Autolaunched: Scheduled-Triggered Flows
- Autolaunched flows can be set to run on a set schedule and frequency, IE, a certain date and time, and a frequency of once, daily, or weekly
- Use the $Record global variable to update the batch record
- Autolaunched: Platform Event-Triggered Flows
- Autolaunched flows can be configured to automatically run upon receiving event messages from a platform event the flow is subscribed to
- Can access all available records and do not need to be associated with an object
- $Record contains the field values from the platform event message, which can be used throughout the flow
- Slack Notification
- Slack notifications can be sent from Salesforce using the Send Notification core action in Flow Builder
- More complex requirements can be met by using the invocable action API
- Salesforce for Slack integrations must be enabled and configured in Setup
- Sales Cloud for Slack should be installed and connected with Salesforce in Slack
- Flow Running Modes
- Changing the running context is supported in screen flows and autolaunched flows
- System Context with Sharing: object-level and field-level security is ignored, but record-level access is enforced
- System Context without Sharing: object-level, field-level, and record-level access are all ignored
- Prebuilt Flows
- Salesforce provides prebuilt flows that can be used to meet typical business requirements. Examples:
- Create a Case, Reset Password, Verify Identity
- Salesforce provides prebuilt flows that can be used to meet typical business requirements. Examples:
- Error Handling
- Using Fault Paths in flows lets the flow remain robust to unexpected validation errors, “record not found” errors, etc, and display or relay meaningful error messages to end users to help debug issues more efficiently
- Screen Flows provide a Roll Back Records element that can be used to cancel all pending record changes in a current transaction
- Debugging Flows
- Paused and Failed Flow Interviews list view in setup allows viewing failed interviews of Screen, Record-triggered, Schedule-triggered, Autolaunched flow types
- When an unhandled error is encountered in a flow interview, an email is sent to the user who last modified the flow or the Apex exception email recipients
- Reference FoF Slides for more
- Orchestrator
- Salesforce Orchestrator can be used to create an app with multi-step processes that interact with multiple users, called Orchestration
- Flows are distinct from Orchestrations:
- Flows automate simple to complex business processes by collecting data and triggering actions like record updates/creation, sending email, among other things
- Flows are record-centric
- Orchestrations combines and coordinates a series of flows to create advanced and automated business processes
- Orchestrations are user-centric
- Orchestrations have:
- Stages: stages group related steps that are executed successively, one at a time. Exit criteria determine when a stage is considered complete
- Steps: either interactive or background
- Interactive steps are assigned to a user, group, or queue since it requires user interaction
- Background steps are launched as an auto-launched flow and require no user interaction
- Ideal applications for orchestrator:
- Advanced approval processes, shipment processing systems, HR Onboarding processes that include multi-steps and multi-user tasks, group task list
- Set up orchestrations using the Flow Builder (Setup > Flows > New Flow). Orchestrator tiles contain Orchestrator-specific elements.
- Multiple interactive and background steps can be added to a stage
- Decision elements perform the function of an if-then statement
- Orchestration items are listed on the Orchestrator Work Guide component and Orchestration Work Items list view
- Migrate to Flow Tool
- Migrate to Flow tool automatically converts a Workflow Rule to a corresponding record-triggered flow