Migrate to Flow Best Practices

It finally happened: Winter 23 is here. You cannot create new workflow rules (WFRs) anymore.

Migrate to flow functionality is GA (Generally Available).🔥 Before I get into the details of this topic, let me tell you that all my courses are on a huge sale. Check below. 🔥What do you do now? Use this, and a couple of clicks later, your Org will be all on flow? Not so fast.

Let’s review the facts here.

Workflow rules support:

  • 🔁 Field Updates
  • 📧 Email Alerts
  • ☑️ Task Creation
  • 🕊 Outbound Messages

You can do all these things with flow.

First, review all the WFRs you have in our Org. Main parameters to look at (make a table out of this): 💡

  • Object (Opportunity)
  • Trigger (On Create)
  • Criteria (When Close Date <= Today + 30)
  • Action (Email Alert)

Why can’t you just use migrate-to-flow and migrate everything? The limitations are: 😰

  • Does not support tasks
  • Does not support long text fields in the criteria
  • Does not support cross-object reference in the criteria
  • Migrates one WFR to one Flow
  • Does not facilitate renaming/relabeling the flow (same name – renaming manual)

There are several approach alternatives you need to consider:

1️⃣ Custom Development: Analyze and design & build everything

2️⃣ Use migrate to flow when it works: One-to-one migration

3️⃣ Try to create one flow for most WFRs: Major work & Maintenance nightmare

4️⃣ Hybrid: Design your own strategy combining the methods above

I looked at all these factors and come up with a set of recommendations. I reviewed the recommendations in a Salesforce Saturday meeting with the awesome Salesforce ecosystem friends this past weekend. Here is a few of them:

  • Use migrate to flow for Email Alerts. Rename flows to follow a convention. One-to-one migration. Exception: Long text field reference in criteria (LongText is not blank)
  • Fast field updates should be combined in before-save flows. If you have too many variations of workflow criteria, do not force everything into one flow. Come up with logical divisions and split them into multiple naming the flows accordingly.
  • Tasks should be combined in after-save flows. On objects where there is an after-save flow already, the field updates can be included in one after-save flow.
  • When combining many WFRs with various different criteria into one flow, decisions get overly complicated. No access to a formula builder. Split if needed.

Please check the presentation pdf at this link for more information.🔥 All my courses are on a huge sale: ðŸ”¥

  • My bestseller Udemy course is on sale for $9.99, the lowest price of the year. Buy it now and get lifetime access to the course and the reshoot that will be published by the end of 2023. I will publish a new code here every week until the end of October. Click here to buy or use the code: OCTOBER1
  • My bootcamp-style six-week long Advanced Flow course is on a 50% sale. Buy it now and start the course on the 8th of January. Start the year strong: Click here to register.

This post was originally made to LinkedIn on October 17, 2022.

Read the previous post: AND(NextStep = “GoWithTheFlow”​, OR(Type “WFR”​, Type “PB”​))


Advanced Topics & Resources

Hello folks,

Let’s talk about advanced topics around flow automation this week.

I want to highlight two sources of information that Salesforce recently published.

One of these resources is the blog post titled “Your Guide to Determining the Flow Running User and Its Execution Context” by Jennifer W. Lee.

It has been a mystery for many flow builders what context different flow types run. For example, if I create a record-triggered flow, can it update all records in my Org? What happens when I activate and run an event-triggered flow. All these questions have been answered in this blog post.

One interesting observation for me is the information that Jen published on screen flows. I built a few screen flows that run on public community (digital experience) pages, and even when I set the flow to run in system context without sharing, it would not see the related records in the Org it would need to see. So I would have to set up sharing rules to share the records I need in advance for the guest user to see. This phenomenon is explained in this blog post: The lookups in your screen flow do not run in the system context without sharing. Please read the blog post here.

Another source of information is the Architect’s guide to record-triggered automation. I should clarify and say that this has actually not been recently published. There was an earlier version of this page. This is not merely an update. The whole thing has been rewritten, and it is immensely more helpful than the previous version. There is good information for any level, but I would like to emphasize that some parts of the post are very advanced. Do not be alarmed if you don’t understand everything. This is expected.

If I had to highlight one point out of this document, it would have to be the use of formulas. There is an interesting bit of information, and it essentially says that the use of complex formulas does not scale well in high-volume flow execution scenarios.

This is the reason I often use a formula field and refer to it in my flow when I deal with a very complex formula. The best architectural solution will depend on the type of flow you are building, how often it will be executed, and how frequently the object records are pulled up and viewed in the Org.

I wanted to go into this topic also to emphasize this point: Capable flow builders are not that uncommon, and there are many great admins on the platform, but a flow builder who is very knowledgable on the platform’s capabilities and can harness both sides to come up with a great solution, is a rare gem. Read the architect’s guide here.

Recently published resources:


P.S. Originally published on 04/10/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.