Schedule-Triggered Flows: Salesforce Flow Builder 101

Last weeks Salesforce Flow Lesson gave us the Screen Element - providing you with the tools to capture data in a customisable UI to then update or create records. This week we look at the inverse - a Flow that will run on a schedule without any interaction from a user, helping you ensure your Orgs data is automatically up to date at all times. Introducing Schedule-Triggered Flows.

But first a recap – Salesforce Flows are the future of automation in the Salesforce Platform. I’ve previously spoken about what the current automation landscape looks like, and Salesforce has been transparent about the future deprecation of Workflow Rules and Process Builder. This is the second in the series where we talk about how to use various Salesforce Flow elements.

We’ll start with our example business case.

The VP of Sales at Company, Inc has found that due to the high volume of incoming leads some are getting missed. They feel that the Lead object should have a customer field for Priority (with Low, Medium, and High), and that if a Lead has not been contacted in a day that the priority should be changed to High so that it is follow up the first thing in the next business day to ensure a strong customer experience from their first contact with us.

As a variation to this, the VP of Sales has stated that depending on the volume of incoming leads it may not viable to have the priority set to High after one day, and that they may you need to update this status every several days instead.

As always we’ll start with the finished product first and show how we got here.

Schedule Triggered Flow

Schedule Triggered Flow with Decision Element

This flow is simple to implement with a single update record element to add with the flow running at a specified time daily. Before we create our flow though - head to Object Manager and create the customer Priority field on the Lead Object.

Once your field is created to track the priority of the Lead it is time to create the Flow. From the business requirements we want this flow to run daily, and to update the records automatically. We do not need any input from the user for this to happen, and as this flow is being triggered at a time interval (not due to a record update) we select the Schedule-Triggered flow.

Thankfully this requires fairly minimal configuration. Set a schedule for the flow to run (choosing the start date, and time, and then the interval).Select the object, and filtering conditions. For our use case this is the Lead object, where the status is ‘Opened - Not Contacted’.

With the filters applied our flow will collect all records for the Lead object where the status is Opened - Not Contacted, and repeat this daily. Once our records are collected we then need to change the priority to high. We can do this through the Update Record element.

And that’s it. Super easy.

Debug before activation (and ensure that rollback mode is selected) as a best practice prior to activation.

Now that we have a strong foundation for our flow, we can then duplicate it and create our variant business requirement.

An immediate thought may be to change to run the Flow to run weekly instead of daily - but this won’t have the desired effect. If the Flow is changed to run weekly it will update all the records on that day of the week regardless of if the lead is 1 day old, or 7.

Instead we can use the Decision Element to add a filter.

Like the first version of this flow we collect all of the Lead records in one basket that have not been contact, but with our Decision Element we can then filter this further. By filtering the creation date based on a formula (TODAY() - n, where n is the specified number of days) our flow will still run daily but only update the records when they have reached our required age. This provides a flexible point from which to partner with the VP of Sales to further refine.

For our use case we will keep the flow to update records every day. While it has passed debugging it is worthwhile testing with a larger volume of records before pushing to production - our developer org has some test data here for this purpose. 

Adjust the start time of the flow to run shortly after the current time and await the results.

Before

After

Now that we know the flow is passing debugging, and works with multiple records we can feel confident pushing this to our production org.

See you on the Trail.