Creating a Schedule-Triggered Flow in Salesforce: A Step-by-Step Guide

With the end of support for Process Builder and Workflows fast approaching, the transition to flows has become inevitable for many Salesforce Admins. As someone who has always felt quite at home with Process Builder and Workflows, I’ll be the first to admit that learning flows can be a bit overwhelming at first. They offer a great deal of flexibility, but the complexity that comes with them is undeniable. This is what makes flows so powerful in automating processes across a Salesforce org!

From Screen Flows to Autolaunched Flows and Record-Triggered Flows, there are many types to explore and suit different needs. In this article, we’ll be focusing on Schedule-Triggered Flows – one of the many ways to bring automation to the next level. Join me on this Flow learning journey, and let’s dive in…

What Are Schedule-Triggered Flows?

If you’re not a newbie admin, then you probably remember scheduled actions in Process Builder as well as Time-Based Workflows. These flows allow you to automate tasks on a scheduled basis, eliminating the need for manual intervention while ensuring processes run smoothly at set intervals.

Schedule-Triggered Flows have the same purpose but are more powerful than both Workflows and Process Builder. The transition to Flow can feel like a daunting task for some admins, and I believe a big part of that is because of the increased capabilities (and complexity!) that these flows offer.

While Time-Based Workflows and Process Builder scheduled actions require specific criteria to be met before they can be triggered, Schedule-Triggered Flows are more powerful in the sense that they only need a start time. They allow you to automate processes on a scheduled basis without the need for user input.

Schedule-Triggered Flows can be set up to run either once off, every day, or every week as required, and are run separately for each record in the batch. So whether you want to update records, send out email notifications, or perform calculations at specific intervals, they can give you the flexibility to do all these processes automatically.

I remember keeping my eye out for actions done under “Automated Process User” back when I was working for Salesforce Support and troubleshooting issues. When setting up a Schedule-Triggered Flow, it’s important to remember that it runs as the Automated Process User by default. This is the user under which the Flow will execute.

If you want it to show up as the admin’s name (you!), make sure to configure the Workflow User under Setup > Process Automation Settings > Default Workflow User.

Prerequisites

Before creating a Schedule-Triggered Flow, ensure you have the following:

• Appropriate permissions to create and manage flows. This is provided by the Manage Flows and Run Flows user permissions that can be assigned via Profile or Permission Set > App Permissions.
• Access to Flow Builder in Salesforce Setup.
• A clear understanding of the process you want to automate. Consider sketching the whole process out on paper before going straight into Flow Builder (I know it’s tempting to just start clicking!). Remember, your Flow would be automating manual steps, so it’s good to have a map of which manual steps lead to what before actually doing them on Flow Builder.

For our walkthrough, I would like to demonstrate how different and more powerful creating a Flow is compared to Process Builder or Workflow Rules. With that in mind, I have decided to take on a use case that cannot be done with both of the aforementioned features.

TechSmart Inc. is a company specializing in electronics, frequently hiring temporary or seasonal sales staff to manage demand surges during peak sales periods such as the holidays or product launches. As a result, the sales team roster is dynamic, with employees who may not always remain with the company long-term.

Most Sales Team activity for the week is finished by Saturday afternoon, making 3:00 pm an ideal time to run this Flow. Running it at this hour ensures minimal disruption since it falls after the busiest hours yet while users are still likely to be online or awake to receive the deactivation notice. Choosing this time also avoids the visibility issues that can arise with early morning or overnight runs, ensuring that users receive the email promptly and have time to take action if they’re still active with the company.

Goal: Create a Flow that deactivates active sales team members who have not logged into Salesforce in over 60 days. This Flow should run weekly on Saturdays at 3:00 pm. Users should receive an email notification, giving them time to log into Salesforce within the following week to prevent deactivation if they are still with the company.

Before we dive in, I want to let you know that the steps below not only walk you through how I created the Flow but also share my thought process and a minor challenge I encountered as I learned Schedule-Triggered Flows from an admin’s perspective.

Trust me: I didn’t instinctively know where each element belonged or whether a value field would accept a formula – it took me a bit of trial and error if I’m being honest. Think of this as a tech diary or raw documentation of my journey. I hope it reassures fellow Flow beginners that running into these hurdles is completely normal. You’re not alone!

Planning the Flow

I’ve always been a visual person, so I find it a lot easier to map out my Flow on paper or outside Salesforce before executing it in Flow Builder. You can draw a flowchart that outlines all the processes and decisions involved in your use case or write down questions and answers involved.

It doesn’t have to be perfectly accurate, as we’re just in the planning stage, and we’re not sure whether this plan could actually be executed in Flow Builder as it is. Think of it like a rough draft or idea dump. This approach can help you visualize the structure and logic more clearly when building. In this scenario, I start with simple questions of who, what, and when – for example:

• Who are the users involved?
• When does the Flow run?
• What actions will it be required to do?

The answers to these questions will help map out what you need to do to solve the ‘how’ questions that come after.

• Who are the users involved?
  • Sales team members
• When does the Flow run?
  • Every Saturday at 3 pm
• What actions will it be required to do?
  • Deactivate active sales team members who have not logged in to Salesforce in over 60 days
  • Send a warning email to these users

How…

• …do we identify sales team members?
  • Using their profile ID or profile name
• …do we deactivate these users?
  • Uncheck the “Active” checkbox on their user record
• …do we send a warning email to these users?
  • Set up an email template and email alert
• …do we know whether a user has logged in to Salesforce in the last 60 days?
  • Through the date on the Last Login field on their user detail

Here’s how I initially pictured the Flow process:

Walkthrough: Creating the Flow

To begin, navigate to Setup and type “Flow” in the quick find box. When you see “Flows” in the results, click on it to view all flows in your org.

Hit “New Flow” on the upper right. This should open the Flow Builder on a new tab, with a prompt for you to choose between starting from scratch or using a template. Select “Start From Scratch”.

The next prompt should ask for your preferred Flow type, in which we select Schedule-Triggered Flow. Click “Create” on the bottom right.

The first thing that it asks is for you to set a schedule. Our question, “When does the Flow run?”, comes in handy here. Since we’re planning to run it every Saturday at 3 pm, I picked a Saturday in the future and set it to run weekly after that.

Once that’s in, click “Choose Object” and select “User” from the dropdown list. Now, we need to think about what qualifies a user for deactivation. So far, we have three:

1. The user is still active.
2. The user is a sales team member (assigned the sales profile).
3. The user has not logged in for more than 60 days.

For condition requirements, set it to “All Conditions Are Met (AND)” and set the first condition.

Let’s think about how to make the Flow identify our remaining conditions:

The user is a sales team member.

You can identify if a user is a sales team member through their profile – they have to be assigned to the sales team profile for this condition to be met. We have two potential values to identify a user’s profile: the profile ID and the profile name.

Since hard-coding IDs is not the best practice, we’d have to go with the profile name. In an attempt to add the profile name to the entry criteria, I searched for “profile” and came up with no results besides “ProfileId”.

Seems like I can’t have that identified in the entry criteria, so we’ll find a way to identify that later in the Flow.

The user must not have logged in during the last 60 days.

My initial thought was to use the user’s Last Login date value. I should have a date to compare it to, and in this case, we must identify whether the last login date is earlier or later than 60 days ago.

But how do we identify “60 days ago”? The date for “60 days ago” can be calculated by subtracting 60 days from the date today. Let’s do this in a formula:

Click the sidebar icon on the upper left to bring out the toolbox. Hit “New Resource” and select “Formula” as the Resource Type. Fill out the rest of the fields and select “Date/Time” as the Data Type. The formula should be as shown below, which indicates today’s date and time minus 60 days. It’s good to fill out the description field as well, so it’s easier to remember what this was specifically made for. Remember what API name you set (mine is “nowminus60”) and select “Done”.

Here’s what we have so far:

• A schedule for the Flow to run.
• Entry criteria for a user to enter the Flow (User = Active).
• A formula that calculates the date 60 days ago from today.

Now, let’s break down what should happen after the entry criteria:

• Identify whether the active user is a member of the sales team.
• Identify whether the user has logged into Salesforce in the last 60 days.

Once the Flow sees whether a user is eligible for deactivation or not, it should ‘decide’ the next action. At this point, it’s logical to add a decision element next.

Hit the plus sign to add an element, and select “Decision”. Fill out the Label, API Name, and Description in the next window. Here’s what I did for mine:

At this point, we decide how many choices this element has. The three possible scenarios are:

1. The sales user will be sent a warning email, stating that they will get deactivated if they don’t log in within the next week.
2. The sales user has already been sent a warning email and has not logged in the week after receiving the email – this sets them up for deactivation.
3. No action – the user has logged in within the last 60 days.

Let’s focus on no. 1 and break down what we need to accomplish it:

The sales user will be sent a warning email, stating that they will get deactivated if they don’t log in within the next week.

• The user is a sales team member (assigned to the sales team profile).
• The user has a last login date (the field is not blank).
• The user’s last login date should be earlier than (less than) 60 days ago (“nowminus60” – the formula we made previously).
• The user has not been sent a warning email yet.

On the New Outcome tab, fill out the Label and Outcome API Name. I named mine “Warning” to signify that this decision outcome is for users who will receive a warning email. For the conditions, let’s start with the simplest one: identifying whether or not the user is a member of the sales team.

Click the Resource box and type “Triggering User”. This looks at the user who triggered the Flow. Clicking the result should show you a new set of options, wherein we select “Profile ID”.

Note: There will be two options for “Profile ID” – the one with the arrow on the right and the one with none.

Since we mentioned earlier that hard-coding IDs is not the best practice, we can’t select the “Profile ID” option and leave it at that. Make sure to click “Profile ID >” so we have the option to select the profile’s name instead. The result will look at the profile name of the user who triggered the Flow. Keep the operator to “Equals” and then type the profile name under Value.

In my org, the profile name is “Sales Team”.

Here’s where we’re at on our checklist so far! It’s time to move to the next one.

• The user is a sales team member (assigned to the sales team profile).
• The user has a last login date (the field is not blank).
• The user’s last login date should be earlier than (less than) 60 days ago (“nowminus60” – the formula we made previously).
• The user has not been sent a warning email yet.

The User object has a standard Last Login field, which is viewable when accessing a specific user’s details through Setup > Users. Let’s set our next condition so that this field is not blank (the user must have logged into the org at least once in their whole Salesforce life).

We can do this by setting up the condition like this:

• Resource: Triggering User > Last Login
• Operator: Is Blank
• Value: False

Let’s now move on to our next condition. Going back to our checklist, we’ve checked off the first two.

• The user is a sales team member (assigned to the sales team profile).
• The user has a last login date (the field is not blank).
• The user’s last login date should be earlier than (less than) 60 days ago (“nowminus60” – the formula we made previously).
• The user has not been sent a warning email yet.

To identify whether or not the user has logged in to Salesforce in the last 60 days, we can compare the user object’s standard Last Login field value to our formula, “nowminus60”. If the last login date appears to be earlier than (less than) “nowminus60”, the user should be sent a warning email.

We can do this by inputting the following for the next condition:

• Resource: Triggering User > Last Login
• Operator: Less than or equal
• Value: nowminus60

Great! We’re almost through our checklist. Let’s move on to the last one.

• The user is a sales team member (assigned to the sales team profile).
• The user has a last login date (the field is not blank).
• The user’s last login date should be earlier than (less than) 60 days ago (“nowminus60” – the formula we made previously).
• The user has not been sent a warning email yet.

The question here is: how do we identify whether or not a warning email has already been sent to the user?

The easiest solution I could think of at this point is to create a checkbox on the User object. The checkbox should be “Checked” once a warning email has been sent. Otherwise, the default value of the checkbox is “Unchecked”.

We are yet to create this checkbox, though! Let’s get started by opening a new browser tab, letting Flow Builder run in the background for a bit, and opening Setup > Object Manager > User > Fields & Relationships. Navigate to New > Checkbox > Next. Give it a label and description, then make sure to keep the default value “Unchecked”.

Hit “Next”, adjust field-level security and page layout settings according to your preference, and save.

You can then go to Setup > Users and click any user to check and make sure your new checkbox is visible on the user detail page.

Now that we have this identifier, we have to tell the Flow that as long as this checkbox is unchecked, the user has not received a warning email yet. This branch of our decision element should send out a warning email to the user, so our condition should be an unchecked checkbox.

Going back to the Flow Builder tab, I’ve decided to make this a saving checkpoint. This is to ensure I don’t lose all the progress made so far in case something goes wrong and so we can refresh the page and get the new checkbox to reflect within Flow Builder as an option for our last condition.

Click “Save” on the upper right, give your Flow a label, API name, and description, and save.

Okay, back to our condition! Do a little page refresh and input the following values:

• Resource: Triggering User > Warning Sent?
• Operator: Equals
• Value: False

Great! We’re finished with all the conditions. Now, let’s fix the condition requirements to consider not only users who meet all the conditions but also those with blank Last Login dates (users who have never logged in).

Click the dropdown for “Condition Requirements to Execute Outcome” and change it to “Custom Condition Logic is Met”. A new field for condition logic should appear, where we can further customize the operators. We can freely use AND, OR, and NOT for this. I’ve updated its value to the following:

(1 AND 2 AND 3 AND 4) OR (1 AND NOT(2) AND 4)

Check out the table below with logic operators, their definitions, and examples:

(1 AND NOT(2) AND 4) is the part that considers users who have never logged in. NOT(2) indicates a blank Last Login field, which explains why condition 3 (which compares the Last Login to nowminus60) is no longer significant and is not included here.

We’re now done with our checklist for our first outcome. Let’s work on the second outcome and create a new checklist for it, similar to the first:

The sales user has already been sent a warning email and has not logged in the week after receiving the email – this sets them up for deactivation.

• The user is a sales team member (assigned to the sales team profile).
• The user has a last login date (the field is not blank).
• The user’s last login date should be earlier than (less than) 60 days ago (“nowminus60” – the formula we made previously).
• The user has already been sent a warning email.

Looking at the checklist, it’s exactly the same as our first outcome checklist, except for the last item: the user has already been sent a warning email. In this case, the user was warned, but they still have not logged into Salesforce in the past 60 days, so they’re all set for deactivation.

Click the plus sign next to “Outcome Order” and give it a label and API name. I’ll name this “Deactivation”, and I’m copying all conditions and condition logic from the first outcome, except that the last condition (Warning Sent Checkbox) must be “True” instead of “False”.

And that finishes our decision element! We’re halfway through the whole Flow, and it’s supposed to look like this so far:

With our decision outcomes set up, it’s time to tell the Flow what actions it must take for each outcome. Let’s start with the warning outcome. Two things must happen:

• A warning email will be sent to the user.
• The “Warning Sent?” checkbox will be ticked.

Let’s start with creating the warning email. Open a new browser tab (let’s allow Flow Builder to run in the background again for a bit) and navigate to the App Launcher > Email Templates. Click “New Email Template” and fill out the required fields, description, and message content.

Hit “Save”. Now, let’s make an email alert with this template by going to Setup > Email Alerts > New Email Alert. Again, fill out the fields (set the “Object” to “User” and your “Email Template” to the one you just created).

For the recipient type, change the “User” to “Email Field” and add “Email Field: Email” to the column on the right.

Select a “From Email Address”, then hit “Save”.

Let’s return to our Flow Builder tab and do a save checkpoint to keep our progress so far. Click “Save” and refresh your tab, so that our new email alert will appear as an option when we set it up.

Click the plus sign below the “Warning” outcome and select the “Action” element. In the search action box, type “Email Alert” and select the only result. Click the name of the email alert we just created, give it a label and description, and add Triggering User > User ID as the input value. It should now be added as a Flow action under the Warning branch.

Note: I used an email template and email alert combo for this step, as it’s what I’m most familiar with, coming from dealing with Process Builder and Workflow Rules. However, this is not the only way to send an email through Flow. If you already have a template ready in your org, the template ID can be called out directly in the Flow Builder action without needing to create an email alert. Alternatively, if you don’t have both a template and an alert, you can opt to use a Text Template within the Flow Builder and select it in the Send Email action. It all depends on your email content and what you’re trying to achieve!

That crosses out the first item on our checklist! Let’s work on the next one:

• A warning email will be sent to the user.
• The “Warning Sent?” checkbox will be ticked.

Click the plus sign under your warning email alert to add another action to the same branch. This time, select “Update Records”. Give it a label, API name, and description. Keep the rest at the default value, and set the “Warning Sent Checkbox” to “True” under “Set Field Values for the User Record”.

That completes our checklist! We’re almost there – just one more outcome to go. It’s time to set up the action for deactivation.

I don’t think we need to make a checklist here, since only one action needs to be done when deactivating a user: the active checkbox on the user record must be unchecked. Can you guess what action we’ll be using for this?

You’re right – it’s another Update Records action. We’re essentially changing the active value from “True” to “False”.

Click the plus sign under the Deactivation branch and select “Update Records”. Fill out the fields for Label, API Name, and Description, then set “IsActive” to “False” under “Field Values for the User Record”. Keep default values for the rest of the settings.

And we’re done! As a final tip, consider adding fault paths to handle any unexpected issues that may come up. This can help ensure that even if something goes wrong, you’re prepared to manage it effectively.

But for now, take a good look at your new Flow.

Click “Save”, and activate when you’re ready to run it in your org. Your Flow then automatically checks for inactive users starting Oct 12, 2024, and every seven days after that.

Whew, that was pretty long! This article discusses only the creation process, but ideally, a Flow should also be tested and debugged before activation. Fortunately, debugging for Schedule-Triggered Flows has recently been improved! It’ll now be easier to catch potential issues before they impact your org. However, let’s save that deep dive into testing and debugging practices for another time.

Summary

So far, we’ve explored the key aspects of Schedule-Triggered Flows – from understanding what they are and the prerequisites needed, to planning and creating a Flow using a real-world example.

I hope that the foundation we’ve covered will give you enough confidence to start building your own Schedule-Triggered Flows. I know that, from a beginner admin’s simpler perspective, Flow capabilities and elements can get pretty overwhelming, even with a simple use case or end goal. But with time and constant practice, you’ll be able to fine-tune and optimize your Flow skills.

What Flow type do you think we should walk through next? Leave your answers in the comments below!