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. To solve for that without writing code, you can create a schedule-triggered flow.
In this post, we’ll provide a high-level overview of schedule-triggered flows, give you use cases solved with a schedule-triggered flow, and show you an example schedule-triggered flow to inspire you to build your first one. Let’s get started!
A schedule-triggered flow runs in the background at a specified time and at a repeated frequency (daily, weekly, or once) to perform actions on a batch of records. Schedule-triggered flows can save time and minimize manual data update risk by automating these updates. Schedule-triggered flows can be monitored and managed in Setup from the Scheduled Jobs page. You can schedule flows to run in off-hours to minimize potential record conflicts with users. A schedule-triggered flow runs independent of a record change.
From the New Flow menu, select Schedule-Triggered Flow to start building your new flow.
While batch Apex and a schedule-triggered flow look like siblings, think of batch Apex as the much older sibling capable of handling many more records with more capability than its younger sibling, the schedule-triggered flow.
Batch Apex is code written by a developer to process records in batches. Schedule-triggered flows are a low-code version of a scheduled batch Apex. Unlike batch Apex, which can query up to 50 million records, a schedule-triggered flow can only query up to 50,000 records before hitting the governor limit.
The maximum number of schedule-triggered flow interviews per 24 hours is 250,000, or the number of user licenses in your org multiplied by 200, whichever is greater. One interview is created for each record retrieved by the schedule-triggered flow’s query.
The maximum batch size for schedule-triggered flows is 200, whereas for batch Apex it’s 2,000.
Batch Apex can handle tasks that need to be performed at regular intervals, such as hourly, daily, weekly, or monthly and offers more flexibility than schedule-triggered flows.
Consider the data, the number of records, and frequency of the scheduled process when determining the right solution to meet your business requirements. If your process must accommodate for large volumes of data or more scheduling flexibility, schedule-triggered flows may not be the right solution to get the job done.
There are many use cases that are solved with a schedule-triggered flow. Here are a few that come to mind.
What are other use cases you can think of?
Fight the inclination to go into Salesforce and start building in Flow Builder. 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 and go to Setup. It’s much easier to make changes on paper (or electronically) than to have to reconfigure a flow.
Remember, you’re automating manual steps, so think about which actions you take that you need to tell Salesforce to do on behalf of the user, including making decisions. If you search for open cases and find some, now what do you do? What if you search for open cases but don’t find any? This process map becomes your guide to building your automation.
I’ll do you one better and show you two examples of a schedule-triggered flow!
Our first scenario is pretty simple. This use case covers the situation where we introduced a new picklist to the Opportunity object and, as expected, existing records don’t have a selected picklist value. The business would like the existing records to default to ‘Not Provided’ instead of displaying a blank value. An admin can use Data Loader to extract the records, set the value, and update the field in existing records. Our #AwesomeAdmin Addison Dogster decides to do a one-time bulk update using a schedule-triggered flow. In this flow, she’ll find all the opportunities that have a blank Favorite Cupcake picklist field and then update the field to ‘Not Provided’.
Addison starts off her schedule-triggered flow by setting the schedule—Start Date and Start Time. Note: You need to set the schedule to a future date and time, as a schedule-triggered flow can’t run on a date/time that’s already occurred.
Addison maximizes performance by specifying the object and filter conditions to narrow the records to only those she wants to run through her schedule-triggered flow. For this automation, she only wants to look for opportunity records where the Favorite Cupcake picklist field is blank, so Addison specifies the object as ‘Opportunity’ and the filter condition as ‘Favorite Cupcake__c Equals Empty String (Not Null)’, which means the field is blank. If this condition is not met, that opportunity record is not run through this flow.
The one and only step in this schedule-triggered flow is an update to the record using an Update Records element. Here, Addison uses the $Record global variable, which refers to the opportunity record her schedule-triggered flow is running through the process. Note: You can set further filter conditions to narrow the opportunity records that are updated. But in Addison’s case, all opportunity records that make it past the entry condition will have the picklist value of the Favorite Cupcake field updated to ‘Not Provided’.
Testing and debugging schedule-triggered flows is fairly limited. Unlike a record-triggered flow or autolaunched flow where you can specify the record to use to debug, if you debug the schedule- triggered flow, it will automatically take the oldest matching record.
In Addison’s case, the oldest opportunity record is ‘Express Logistics and Transport Deal – 4/25/2021’. When Addison ran debug in her schedule-triggered flow, the flow used that record to update.
If you’d like better control over debugging your flow, I’d recommend creating a schedule-triggered flow that sends the record information into a subflow (aka autolaunched flow). That way, you can use the debug feature to test your subflow portion of your schedule-triggered flow with specific records to validate the expected outcome.
Our second scenario is a bit more complicated—and cooler. (This is a simpler version of something I built when I was a Salesforce customer.) Addison wants to automate user deactivation if it’s been over 90 days since the user last logged in to Salesforce AND the user has the Service Rep profile. Addison wants to send a warning email 7 days before they will be deactivated so the user can prevent deactivation by logging in before it hits the 90-day threshold.
Let’s break down this schedule-triggered flow. It’s scheduled to run daily at a set time. (1) It checks the User object for user records that are active and are qualified for auto deactivation (this is a formula field that qualifies the user based on profile). (2) It determines whether the warning threshold has been exceeded. (3) If the threshold is exceeded, then it retrieves the manager’s email address. (4) The Assignment element adds the user and manager email addresses to a collection variable. (5) We use a Decision element to determine whether the user is within the warning period or has reached the deactivation threshold. (6) If the user is within the warning period, an email is sent to the user and manager letting them know the user is close to deactivation. (7) If the user has reached the deactivation threshold, we deactivate the user record and (8) send the user and manager an email letting them know the user was deactivated.
Schedule-triggered flows behave differently than record-triggered flows and their siblings. Here are a few things to be aware of as you build schedule-triggered flows.
For more schedule-triggered flow considerations, check out Schedule-Triggered Flow Considerations.
Create a simple schedule-triggered flow in a sandbox or create a personal Dev org and start building. When you have a requirement to run automation at a specified time and date, and it doesn’t require that you touch a lot of records, consider building a schedule-triggered flow. There’s no better way to learn than by exercising those automation-building muscles!
As an admin best practice, build and test your automation first in a sandbox and never directly in production.
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, 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 […]
Ever find yourself building the same automation steps to solve different use cases, which results in slightly different flow solutions? So now you have clones of the same automation steps hanging out in multiple flows. And then, goodness forbid you have to make a change to those steps in all those flows? That can be […]
