Tag Archives: Best Practice

Flow

One Big Record-Triggered Flow or Multiple?

I will revisit one of the most popular debates on flow: Do we create one giant record-triggered flow or multiple flows? And should we use subflows?

Here is a little disclaimer: It depends. I’m not too fond of rigid rules, and I am not here claiming you are doing something wrong if you do things differently.

Now that I got that off my chest, I do have an opinion on the topic:

Asking the right question is very important. Is “How many flows should we build per object?” a good question? Generally, I don’t think so. We should ask ourselves: How can I build automation that does not waste system resources, is easily readable, and is easy to maintain?

My priority when I build my flows is that my build should not run unnecessary automation. My most important objective is not to trigger automation when it does not need to run.

In a complex Org, you quickly realize that yields multiple flows per object. When you look at the three tasks that can be performed in one big record-triggered flow, they rarely need to run all in the same scenario.

Now that I told you I heavily use my start element criteria, do I use the formula entry criteria or the line editor with AND/OR operators?

Here is my experience: I often see record-type usage in fairly complex Orgs. I’m not particularly eager to hardcode RecordType Ids in my start element criteria. I prefer to use DeveloperName or Name over Id. And these are only available in the formula editor. So I often end up using the formula entry criteria.

Some of these formulas get very big. But I will give you a simple example:

AND

({!$Record.RecordType.DeveloperName}=”Sales”,

NOT(ISBLANK({!$Record.ContactId})),

   OR(

ISPICKVAL({!$Record.Status},”Scheduled”),

ISPICKVAL({!$Record.Status},”Confirmed”)

      )

    )

 Now let’s get to the other popular topic: Subflows. I recently inherited work that another Salesforce partner did. They did a good job but used subflows in many of their flows. I found the outcome very hard to read and understand. The back-and-forth review left me confused and tired.

I only use subflows if I know I will reuse the logic in another flow.

This post was originally made to LinkedIn on June 19th, 2023.

Read the previous post: Emojis ❤️ and Dreamin’ Events 👌

Standard
Flow

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”​))

Standard