This is going to be controversial but I’m going to say it. The only type of Salesforce flow you should ever use for background automation in Salesforce is an Autolaunched flow!

RemoteCRM-Salesforce-Autolaunched-Flow-For-Background-Automation

Yep, you heard that right, ALWAYS build an Autolaunched flow! Which means don’t build a Record Triggered flow…..and stay away from the Scheduled-Triggered flow. Autolaunched flow is your best friend.

But how do I have my record updates trigger a flow without the Record-Triggered flow? How do I schedule something without the Schedule-Triggered flow? The answer is simple…subflows!

I’m not advocating that you stop using Record-Triggered or Scheduled-Triggered entirely, what I’m recommending is to have them as merely the entry-point or firing mechanism for your automation process which then fires the Autolaunched flow which does all the heavy lifting.

Here’s why:

1. Salesforce locks you into the flow type. Once you start it, there’s no going back and changing the flow type later on. Say for example, you built a Record Triggered flow that uses complex conditions to update the Account status when the account updated. You spent hours building this flow, tested it and it works great! Users love that this calculation is done automatically and now wish you could have the account also update when a custom button is clicked on an Opportunity. Oops! Now you’re going to have to spend hours re-writing the same flow again since it only currently runs when the account is changed. Unfortunately Salesforce does not allow you to copy-paste elements between flows, nor does it let you change the flow type after the fact. You’d have to rebuild that flow again from scratch to invoke it via that button.

Instead: Build it as a Autolaunched flow, and then create a separate Record Triggered flow that launches the auto-launched flow (as a subflow).

RemoteCRM-Salesforce-Autolaunched-Flow-Subflow-Button

This works for the account level change. Now you can also have your custom button on the opportunity trigger this flow, and you have the best of both worlds! The same logic runs regardless of how it’s invoked.

Caveat: You do lose the ability to do “Fast Field Updates” using this method as that is only offered via a Record Triggered flow.

2. Schedule Triggered flows are limited – You are given very limited options to schedule your flow, the most frequent being once daily.

RemoteCRM-Salesforce-Autolaunched-Flows-Schedule-Triggered-Flows

If you need to run something more frequently, sorry you’re out of luck with Scheduled flows! Again if you built this as a Autolaunched flow, you can trigger this flow from Scheduled Apex. You can always also use a separate scheduled flow to invoke the Autolaunched flow as the subflow.

3. Compartmentalize – You always want to use reusable and scalable ways to build and manage your flows. You wouldn’t write a 10,000 line application in a single method or class, you’d break it down into multiple re-usable classes and methods.

RemoteCRM-Salesforce-Autolaunched-FlowsAll-Encompassing-Flow

Similarly, why would you write a single all-encompassing (a.k.a. a nightmare) flow like the one above? All flows should be easily compartmentalized and re-usable. Autolaunched flows give you the most flexibility to break up and to re-use the flow logic and fire it in a variety of ways.

In conclusion, while Record Triggered flows and Schedule Triggered flows do have their uses, and doing away with them entirely is certainly not possible, I hope you see why my strong recommendation would be to always build Autolaunched flows as your go-to flow type moving forward!

This post was originally published here.