Flows are such powerful tools to add to your #AwesomeAdmin toolbelt. They can do a LOT of things and that can be a bit overwhelming especially if you’re new to flow. You’ve probably heard about autolaunched flows, but what are they?
You’ve come to the right place. We’re going to give you a high-level overview of an autolaunched flow, explain some basic flow terminology in the process, and give you a simple example or two for you to follow along and create your first autolaunched flow. Let’s go!
An autolaunched flow is exactly what it sounds like: a flow that is automatically launched by something.
An autolaunched flow is a flow that runs in the background and doesn’t require user interaction. This type of flow doesn’t support screens and local actions. A screen allows your users to interact with information on a screen or view information shown to them. A local action allows you to perform actions in the browser rather than going through the Salesforce server using Lightning components.
You may have heard of some autolaunched flows already, such as a scheduled triggered flow, record-triggered flow, platform event-triggered flow, or subflow.
A scheduled-triggered flow is an autolaunched flow that runs only from a schedule. This flow type doesn’t support user interaction, screens, or local actions. A record-triggered flow is an autolaunched flow that runs when a record is created, updated, or deleted. A platform event-triggered flow is an autolaunched flow that runs when a platform event message is received. A subflow can be an autolaunched flow (or screen flow) that runs when initiated by another flow or orchestration. We don’t have enough time here to go into the details of these four autolaunch types.
There’s also an autolaunched flow that has no trigger. This is a flow that’s started from a custom button, custom link, Apex class, REST API, Web tab, Visualforce page, process, etc., which runs in the background. Note: A subflow falls into this category of autolaunched flow.
Below is a filtered list of flows with the process type “autolaunched flow” in Setup.
There are several use cases that an autolaunched flow can solve. As #AwesomeAdmins, you can build all sorts of cool things with an autolaunched flow without writing a single line of code! Here are just a few that come to mind:
What are some examples of autolaunched flows that you can think of?
It’s important to understand the requirements and overall process and to do your analysis BEFORE you start building your automation. I recommend sketching it out and validating the process with business stakeholders before you log in to Salesforce and go in to Setup. It’s so much easier to make changes on paper than to have to reconfigure a flow. Remember, you’re automating manual steps, so think about what actions you take that you need to tell Salesforce to do on behalf of the user, including making decisions: If I search for open cases and I find some, now what do I do? What if I search for open cases and don’t find any; now what do I do? This process map becomes your guide to building your automation.
As you now know, there are different types of autolaunched flows; and since they’ll each have their own dedicated blog post, this one will focus on the autolaunch flow that doesn’t have a trigger, but isn’t a subflow.
In this example, we’ll use our fictional company Mochi Cupcakes. When a same-day cupcake order is received, the cupcake order is in “Submitted” status and assigned to a same-day priority queue. As a Mochi Cupcakes staff worker, they can assume ownership of the cupcake order, update the cupcake order to “Assigned” status, and notify the customer that the order is being worked on—all with one button click. Pretty impressive, if you ask me.
Addison Dogster, Mochi Cupcakes’ #AwesomeAdmin, will solve this with an autolaunched flow (no trigger) that runs from a custom button on the Cupcake Order page. This is the flow she built.
Addison creates an email template and email alert for the customer notification that the cupcake order is in progress. She could use the Send Email action that’s native in flow, but she wants to use the company letterhead to make it nice and professional looking, so she goes with the Email Alert instead. Addison makes note of the Email Alert’s API name as she will use it to find the email alert later when configuring her autolaunched flow.
Addison selects the Autolaunched Flow (No Trigger) from the list of new flows.
First, Addison creates a variable varCupcakeOrderId that stores the record ID of the Cupcake Order that will be passed to the flow via the custom button. Since this variable holds the ID, Addison made this a text data type. She sets this to be available for input as the recordId value will be passed into the flow.
Addison uses an Update Records element to update the Cupcake Order record where the ID matches the recordId passed in the varCupcakeOrderId.
The Cupcake Order record owner will be updated to the current running user using $User.Id. $User is a global variable for the record of the user running the flow. In this case, it’s our Mochi Cupcakes staff member. .Id indicates that this is the ID of the user. Using $User.Id, Addison can dynamically assign the record ownership to the running user of the flow.
The Cupcake Order status is updated from “Submitted” to “Assigned.”
Next, Addison uses the action to use the email alert send to the customer. She searches for the email alert using the API name from earlier.
Addison tests and saves her autolaunched flow. She then navigates to the flow details page in Setup.
Addison makes note of the flow URL for use when creating the custom button for the staff member to invoke the flow.
Addison creates a custom button in the Cupcake Order object called Assign Cupcake Order to Me. She sets the button behavior to “Display in existing window without sidebar” and sets the Button or Link URL to invoke the Assign Cupcake Order to Me flow. The URL passes the cupcake order ID into the varCupcakeOrderId variable and after the completion of the flow, returns to the cupcake order page.
Let’s break down the URL.
/flow/Assign_Cupcake_Order_to_Me?varCupcakeOrderId={!Cupcake_Order__c.Id}&retURL=/{!Cupcake_Order__c.Id}
Addison adds the custom button to the page layout or to the cupcake order Lightning record page using dynamic actions.
There’s no better way to learn how to build an autolaunched flow but to actually build one! Start exercising your flow automation muscle. Use the example autolaunched flow (no trigger) that Addison built to build your own. You can easily translate this to an Assign a Case to Me solution. Give it a try!
If you’re new to flow, there are two great blogs with relatable videos to teach you the concepts used in flow. Check out 5 New Videos to Help You Understand Tricky Flow Concepts and 6 New Videos to Help You Understand Flow Builder. Also, watch videos from my Automate This! YouTube series. We cover various use cases solved with record-triggered flows, subflows, loops, migration strategy by different Trailblazers, specific flow features you can use in your flows, and much more! I live stream a new episode each month, so be on the lookout.
Admins, have you ever needed to have actions taken in Salesforce if something happens in an external system? Have you ever needed to log an error or notify people if an error occurs? If yes, then a platform event-triggered flow might be what you need. In this post, we’ll provide a high-level overview of a […]
As an admin, you may be given business requirements to perform some type of automation, like maintain your org’s data or complete routine tasks (for example, send an email reminder) on a scheduled time and frequency, such as daily or weekly. Or, you might just need to run automation once on a batch of records. […]
As an admin, there may be times where you want to simplify the process of gathering data from your end users by improving the user experience. This involves minimizing the number of screens and clicks needed to get the job done and increasing the overall efficiency of the process. You want to flex those declarative […]
