Which Object Do You Trigger On?

Hello folks,

Suppose you know you need a record-triggered flow: You want to perform automated steps based on the transactions executing in your Salesforce Org.

If you deal with related records, you know you will be in the after-save mode (a.k.a. Actions and Related Records).

If you have come this far, this means you have already found answers to two essential questions:

  1. What type of flow do I need?
  2. If it is a record-triggered flow, will it be before-save or after-save?

You know that I answer a lot of flow questions on a regular basis. My observation is that folks often struggle with the next critical step:

Which object will I be triggering on?

Based on the previous decisions, we know you are already dealing with at least two objects. However, suppose a junction object is involved, like an Opportunity Contact Role that connects the Opportunity to Contacts or an Opportunity Line Item that connects the Opportunity to the Products. In that case, you may have three or more objects involved.

This is the part where things get confusing:

Which object will I trigger on, and what object(s) will I create/update?

The answer is surprisingly simple when you fill in the blanks in this format:

I want to create/update __ Object records when __ Object records are created/updated.

What you write in the second blank will show you what object you are triggering on.

Once you know that, you will need to go from one Object to the other using the relationships. Depending on the depth and the structure, you may use multiple gets.

I thought I’d step back from technical posts for now and focus on the fundamentals again.


P.S. Originally published on 06/15/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.


How Many Flows Per Object?

Hello folks,

My posts on Twitter and LinkedIn comparing the two flow decision designs attracted fruitful discussions (see my previous email for reference).

Let’s start by discussing the notable recommendations that came out of this comparison:

  • Although this was not the purpose of the exercise, both these flows should have been done as a fast field update. The way they are structured; they don’t do anything other than update the field values on the opportunity that triggered the flow.
  • Comparing the decision designs, the one on the right side took advantage of the powerful decision element we have in flow. We can define multiple outcomes tied to criteria, and they will be evaluated from top to bottom.
  • Please note that we can define an outcome as the first outcome in the decision element to filter out the records we don’t want to update. Please see the decision element outcome order design below. (To show this path to you in my previous email image, I added an assignment and labeled it “Don’t Do Anything”. Obviously, this is not necessary.)
  • One discussion that came out of this was whether we should have multiple update elements after the decision element or use a formula to determine the new value and feed that to one single update element. The formula approach would also eliminate the decision element. I don’t think using multiple update elements impacts performance negatively because they are tied to mutually exclusive conditional outcomes. They don’t ever execute together.
  • One observation that was made is that formulas may impact performance negatively. The claim is that the formula value is calculated after every element in the flow. This is an area that I will need to research, as I don’t know the way formulas are evaluated in flow under the hood.

This week was very interesting because Apex Hours published a clear recommendation at this link to only use “One Record Triggered Fow Per Object Per Type” although Salesforce refrains from making such a recommendation. The verdict on this one is still out. The argument on the side of Apex Hours is: “This idea comes from Apex trigger framework. One flow per object is the only way to enforce order of execution and if you can’t control that, your troubleshooting will be very difficult and soon you will hit the governor limits.” So what Apex Hours recommends is to have one flow or object for before-save and one flow per object for after-save.

The reason Salesforce does not recommend this today is as follows:

You may have multiple flows running on the same object, and you can limit the cases the flows trigger by defining narrow entry criteria (start condition). The specified case criteria can be mutually exclusive. This means that you will be running one flow at a time if you do this right, and even zero flows in some cases.
As you try and bring all these flow elements in one flow together, you will find yourself in a situation where you run this combined flow on almost every record create/update. However, the real performance gain is achieved when you don’t trigger your flow at all.
As you build out your flow, you may want to use subflows for repeating logic, and if you do, you must run your combined flow in after-save mode. You will lose the speed and efficiency of the before-save update. Subflows are not available for before-save flows as of today.
In summary, we are still exploring these options, and I personally don’t like to draw clear lines on what can be done and what cannot be done.

If you have questions or comments on this topic, please feel free to go to one of my social channels and write it under a relevant post.


P.S. Originally published on 11/14/2021.

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.

Flow, New Release

Fast Field Updates in Record Triggered Flows (Winter 22)

The biggest flow change in Salesforce Winter 22 may be the smallest!

After Winter 22 Release: You are presented with one single screen for all your Record-Triggered start element options. When you go to your flow screen & click on the “Record-Triggered Flow” button and then “New”, you see this screen:

Record Triggered Flow Update - Winter 22

Your choices are:

  • Fast Field Updates: This means before-save
  • Actions and Related Records: This means after-save

While there is nothing new here in terms of functionality, this screen may throw you off. This is a welcome change for new learners, while it may be confusing at first for folks who have been building Record-Triggered flows for a while now.

You can also see on the same screen that a asynchronous path functionality has been added.

What do you think of this change? Please let me know your comments.