Make the Transition to Salesforce Flow (3)

(part 3 of 5)

It’s Transition to Flow time!

Salesforce is retiring Workflow rules and Process Builder in the near future. The time to start planning to move your Salesforce automations to Flow is now. In this series of articles, I will explain why this change is occurring, what you need to do and I will even provide you with a plan to migrate all your workflows and Process Builder to Flow.

Creating an Inventory

Training, Tools, Best Practice and Inventory.

Training

Commence training both your administrators and developers on how to build automations with flow.

Concentrate on basic flow training first, to learn the key elements and actions. Create some simple flows to get comfortable with the tools and gradually expand to more complex flows once your team has a good understanding of the basics.

Remember, you can start your basic Flow training here: www.CertifyCRM.com

Tools

There are some helpful tools available right now to assist with your migration project. However, simply applying a “lift and shift” methodology will not work well. The result will simply be a lot of old business rules that are likely out of date being moved to a new technology. Many of your existing automations will be old, inefficient and redundant. Use this as an opportunity to re-engineer them to be more efficient, combine related ones and remove those that are no longer required.

Conversion Tools

If you still think there may be some value in using migrations tools then there is a migration tool available now to convert both Process Builder and Workflow Rules. This is from UnofficialSF.com.

Salesforce have also announced their intention to release conversion tools to assist the migration process:

• An initial migration tool for Workflow Rules translation to Flow will be released in Spring ’22.
• Support for Process Builder migration is currently estimated for Summer ’22 (and dependent on feedback from the initial migration tool).

Flow Extensions

Salesforce are not the only source of additional functionality for Flow. There are numerous extensions available on the AppExchange from both Salesforce Labs and third-party developers.

UnofficialSF.com another option and is one of the most active sources for many useful flow extensions. It is actively supported by several Salesforce employers (in an unofficial capacity), numerous MVPs and developers from the Salesforce ecosystem.

When your team is doing their Flow training, challenge them to review some of these extensions and see where they may be useful in the flows that they will build in the future.

Sample Salesforce Labs extensions:

• Flow Magic Picklists
• Lightning Messaging Utility
• Time Warp

Sample UnofficialSF.com extensions:

• Datatable
• Send Better Email
• Mass Transactor
• Confetti

Best Practice

There are some great best practice tips for creating flows in this article from the Salesforce Admins team. Make sure all your team are up to speed on these recommendations.

How many flows per object?

A discussion on this topic a few weeks ago resulted in the recommendation (from the product team) to have multiple record-triggered flows, with rules such as…    

1. Use the start element criteria to limit the records that will be processed by a flow.
2. If two flows need the same start criteria (or no criteria – and operate on all records), then combine them into one flow.
3. Don’t trigger flows from Process Builder, just use flow.
4. Record triggered flows can be before save, after save and on delete.  Each set of criteria could potentially have three flows.
5. Develop and publish naming conventions for your flows. This will make it easy to identify what a flow does and which object it operates on.

There has been considerable discussion about how many flows per object, should it be like Process Builder where best practice recommends there should only be one automation per object?

The main ones where we need to be careful with having too many flows that may interfere with each other and cause problems with the order of execution are the record triggered flows. These flows can be triggered when a record is created or when a record is updated (or both). They can be run before or after the record is saved.

My recommendations are as follows:

Record Triggered Flows:

A record triggered flow is one that is triggered by an action performed on a record.

You have several choices for the trigger that causes the flow to run:

Schedule Triggered Flows:

Each scheduled flow can be run at a specific time, giving you have control over when they are run. For example, you may perform some weekly updates of all opportunity records that are at a specific stage and some other updates to opportunities on another schedule.

These are unlikely to clash as long as you allow plenty of time for one to run before the next one is scheduled to run.

The only thing to take care with is the scheduled flow may change a record and trigger another one of your record triggered flows. To help prevent this you could add a decision element in the record triggered flow to not run if the user is Automated Process (the user that runs the scheduled flows).

Screen Flows:

Screen flows run when the user clicks on a button to initiate them so it really does not matter how many of these you have. Give them names that identify what function they perform and give the action that is used to launch them a similar name.

Naming Standards

Set some easy-to-use naming standard for the new flows e.g.:

<object>-<flowtype>-<trigger or function>

• Opp-trigger-before-create   (record Triggered flow on an opportunity before create)
  • Opp-trigger-after-create
  • Opp-trigger-before-update
  • Opp-trigger-after-update
  • Opp-trigger-before-delete
  • ———————-
  • Opp-screen-<function> (screen flow)
  • ———————
  • Opp-scheduled-<function>   (schedule triggered flow)

Inventory

Create an inventory of all Workflow Rules and Process Builder, include names, objects, descriptions, triggers, the automation type, complexity (story points*) the new flow name and a space for notes.

* Story points is an Agile term used to describe the amount of effort and complexity involved in a task. It is not measured in hours or days but is measured in complexity and effort. While Agile story points are usually 0.5, 1, 3, 5, 8, 13, 20, 40 or 100 it does not really matter what numbers you use for this exercise as long as you can show that the most complex, difficult flow has a higher number than the simplest one. It is used to help you prioritise, schedule and measure your progress. You can use high, medium, low if you prefer.

This template can be used to document and prioritise your existing automations. 

List of automations:

You can get started on your Flow training here:

www.CertifyCRM.com

Next >> Part 4