How I Solved It: Run a Flow Scheduled Path Based on a Field Change

Background

Meet the Modern Classrooms Project, a fast-growing and visionary organization that teaches teachers to reengineer their classrooms around self-paced, mastery-based learning. I’ve worked with them for the past year to implement Salesforce to run their entire organization, from fundraising to program management. They’re a smart team that knows how automation can make their work and their program more efficient.

One of the most important places Modern Classrooms wants to automate is in communication with teachers and potential mentees during the recruitment process for their core virtual mentorship program. Thousands of teachers have already signed up for each session of Modern Classrooms’ mentorship program, and the organization is looking to reach tens of thousands. So, we need to be as efficient as possible in ensuring that people know where they stand as they express interest, apply for scholarships, and enroll in a session.

Key business problem

Some schools or district partners contract with Modern Classrooms to purchase a block of seats in upcoming sessions, and they want to be able to approve, waitlist, or reject teachers that request one of those spots. So, we built a convenient webform to let administrators view applications and update statuses. When the form is submitted, it changes the Campaign Member status for those applicants, and we can use Flow to send emails based on the new status.

No problem! We just need a record-triggered flow on Campaign Member. When the Status field changes (Status Is Changed = true), depending on what the status is, we’ll send the right email. ✅ Done and dusted!

But the staff of Modern Classrooms realized that partners might need a chance to change their mind about a status change. Clicking Submit shouldn’t trigger emails to the teachers right away; we want an hour or two of delay in case partner staff need to shuffle around seats. ⏲

Sounds like it should be easy. Let’s take that same flow but move the emails onto a scheduled path that sends after a delay of 2 hours.

? Not so fast!
You can only have a scheduled path if your flow entry conditions are “only if updated to meet the conditions”. But you can’t use IsChanged if you select this option.

It seems like you could include a Decision element along the scheduled path with “Is Changed = true”, but that doesn’t actually work. (You can select it as your criteria, but it won’t work as expected. Trust me–I tried.) And scheduled paths can’t access the Record_Prior values, so you can’t compare the prior value to the current value and backdoor your way into an IsChanged comparison either.

? We’re going to have to find another way.

There are actually two ways to solve this. Of course, I only implemented one of them for Modern Classrooms. I’m going to show you the details of my solution and then also give a quick summary of another option.

How I solved it

After turning to the Trailblazer Community for help and some time spent noodling possibilities, I realized that what I needed was a switch on the Campaign Member record that would tell my flow whether or not it should send emails when the scheduled path runs. That way, instead of checking for whether “Status Is Changed = true”, I can simply check if the switch is on, fire the email, and set the switch back to Off. Now all I needed was a way to set the switch to On at the right time.

First, I built a custom field on the Campaign Member object. You could make this a checkbox for real simplicity, but I went with a picklist so I could easily see what the field was set to. (I also have this suspicion we might end up needing more states than simply On and Off later…)

A simple before-save flow can handle setting the switch to ‘Send if the Status’ is changed. Later, the scheduled path in the existing flow will set it back to ‘Do Not Send’ after sending the email, to ensure that other edits to the Campaign Member (that don’t change the Status field) won’t trigger duplicative emails.

Here’s the flow that sets the switch to Send.

The entry condition for this flow is pretty simple: Status field is changed.

As noted, this flow runs before the record is saved (it’s created as a fast field Update). This kind of flow runs very fast, so there’s little performance impact in having this extra flow.

Now, we turn back to the after-save flow that sends emails.

In the Decision element at the start of the scheduled path, we check if these are applications or not (only applications get this series of emails based on changes to status). Then, after two Get Records steps, we have the Decision element that checks whether to send emails or not by looking at the Email Switch field and then, based on the current status, we’ll send the right email.

Now that we’ve built it, we have to test it! Think through all the possible scenarios and enlist some help running your data through its paces. Example scenarios include:

• A campaign member is edited without a change to the Status field. (Should not fire any email; the email switch should remain ‘Do Not Send’.)
• A campaign member is changed from status ‘Interested’ to ‘Accepted’. (The email switch goes to ‘Send’, sends accepted email 2 hours later; switch then goes to ‘Do Not Send’.)
• A campaign member is changed from status ‘Interested’ to ‘Accepted’, then is set back to ‘Interested’ 10 minutes later. (No email should be sent because Interested doesn’t get an email in this flow. The email switch is set back to ‘Do Not Send’ after 2 hours.)
• A campaign member is changed from Status ‘Interested’ to ‘Accepted’, then to ‘Waitlist’ 10 minutes later. (Only the waitlist email should be sent. The email switch goes back to ‘Do Not Send’ at that point.)

If you haven’t done so already, this is the place where I remind you to document what you’ve built. We all procrastinate when it comes to writing docs, but just start writing. Admins who come after you will thank you! Heck, even future you might not remember what you were doing. So document, document, document! Write up the flows you’ve built on your Salesforce wiki (or whatever other system you may use), use the description fields on elements to capture the “what” and the “why,” and don’t skimp on the descriptions for any custom fields!

Business results

It’s a little more complicated than the original flow because we now have two flows (that we need to document and maintain). But with the addition of that simple before-save flow, we now have the email delay we need. And the user experience for the partners filling out our webform is better because we can tell them that they have a window after they change teachers’ statuses before emails go out.

Do try this at home

As with everything in the How I Solved It series, you should adapt what I just showed for your own purposes. There are all sorts of uses for a switch field like I created here.

Let me finish by giving you a trick as you test your flows: Set your scheduled path to run after 0 minutes for the purposes of testing. Trying to test a flow with a 2-hour delay is incredibly frustrating! Even setting the delay to 2 minutes isn’t necessary (and will drive you bonkers waiting). You can set a 0-minute delay, and you’ll see the same asynchronous result of the flow without having to wait more than a few seconds. Just remember to set it back to your desired delay time before you deploy to production and activate.

Resources

• Trailhead Module: Record-Triggered Flows

Want to see more good stuff? Subscribe to our channel!