You are here:
Migrate to Flow Tool Considerations
Review considerations and supported workflow rules and processes for the Migrate to Flow tool.
Required Editions
| View supported editions. |
Considerations for Migrating a Process to a Flow
Review considerations and supported Process Builder processes for the Migrate to Flow tool.
Considerations
Processes with recursion aren’t fully supported. When a process with recursion is migrated, the record is evaluated only one time. Test and make sure that any processes with recursion work as intended after migration.
Processes are migrated as Actions and Related Record-optimized (after-save) flows. If necessary, you can edit and optimize the flow for Fast Field Updates (before-save) after the flow is migrated.
The invoke flow action is migrated as a subflow element instead of an invocable flow action. Subflows run in the same transaction as the parent flow. Any processes with invoke flow actions involving external callouts, external actions, or pauses must be redesigned using an asynchronous path.
You can migrate Process Builder’s
scheduled actions only if you select the single criteria associated with the scheduled
action. If multiple criteria are selected, no scheduled actions are migrated. After
migration, scheduled actions become Flow Builder’s scheduled paths. In the flow, migrated
scheduled actions follow the naming convention ScheduledPath__#. At run
time, the new flow checks for pending actions from the original migrated process and then
deletes them. If a record is updated, any pending scheduled actions are moved to the proper
scheduled path or canceled if the record no longer meets the criteria. If a record isn't
updated when the scheduled action is executed, it executes the process’ scheduled action.
See Monitor Your Processes’ Pending Scheduled
Actions.
You can’t migrate a cross-object reference in a formula.
You can migrate a process that uses a custom metadata reference in a formula. After the migration, the custom metadata reference is used in flow formulas, but you can’t configure it by using the resource picker.
When migrating a time-based process, you must migrate each outcome to its own scheduled action flow. Then activate the new flows and deactivate the process.
Migrate your process to a flow within the same org as the original Process Builder. Don't migrate it to an intermediate org and then deploy it to your target org. When you migrate a process to a flow in the same org, the flow can handle any queued scheduled actions from its process predecessor. If you deploy the flow to a new org, it's treated as a new flow, and scheduled paths are not migrated to new scheduled actions.
Supported Processes
The Migrate to Flow tool supports only record-triggered processes. Custom event and custom invocable type processes aren’t supported. The tool also doesn’t support processes that contain custom metadata types or criteria that contain a field that’s from a related object (field traversals). For supported processes, you can migrate these action types without additional configuration.
- Record update
- Record create
- Invoke flow
- Invoke Apex
- Email alert
After migration, these action types retain their original positions in the flow, but they require additional configuration to function as expected.
- Post to Chatter
- Quick Action
- Submit for Approval
- Send Custom Notification
- Live Message Notification
- Send Surveys
- Quip-related action types
Considerations for Migrating a Workflow to a Flow
Review considerations and supported workflow rules for the Migrate to Flow tool. Learn manual conversion methods for specific workflow rules.
Considerations
If a workflow rule contains only field updates, the tool converts it into a fast field update (before-save) flow.
Due to their position in the order of execution, record-triggered flows can behave differently from similar workflow rules.
An at-rest pending time-based action is migrated to a scheduled path when the associated record is changed.
Supported Workflow Rules
The Migrate to Flow tool supports workflow rules that contain these items.
- Field-based criteria
- Field updates
- Email alerts
- Outbound messages
- Time-dependent workflow actions
- Rule criteria formulas that are set to true (unless the evaluation criteria are also set to created, and anytime it’s edited to subsequently meet the criteria)
Equal tonullNot equalto null- Rule criteria formulas
Workflow rules that contain the following can't migrate with the Migrate to Flow tool.
- Criteria with no defined workflow actions
- Global variable fields
- Fields on related records
- Record types
- The
does not contain,includes,excludes, orwithinoperators - The
greater than,greater or equal,less than,less or equaloperators on picklist fields - Formulas that use
Hour,Minute,Second,TimeNow,TimeValue,IsClone, or$RecordType - Tasks
- Relative date values in date fields
- Multiple currencies
Manual Conversion Methods
Certain features are unsupported by the Migrate to Flow tool, but you can manually convert them.
To manually convert workflow rules with unsupported use cases in entry criteria, create a Decision element inside the Flow. Then recreate the workflow rule steps with the condition builder.
To manually convert workflow rules that use the does not contain operator, use custom condition logic. For
example, create a condition that uses the Contains
operator in the first condition, and in the condition logic, enter NOT
1.
To manually convert workflow rules that use tasks, use the Create Records option and create a record of the Task object.
Flows support workflow actions for Email Alerts and Outbound Messages. To add these workflow actions to a flow, use the Action element.
To replicate relative date values, such as TODAY or NEXT WEEK, use the Decision
element.
