How I Created a Solution to Test Scheduled Flows Easier During UAT | Automate This!

Testing schedule-triggered flows is challenging

User acceptance testing (UAT) is a critical phase in any software development lifecycle. It's the final checkpoint before a system or feature goes live, ensuring that it meets business requirements and functions as expected. However, testing scheduled flows in Salesforce can be challenging. In this blog, we'll delve into a simplified solution based on a real-world production scenario and discuss a practical approach to streamline UAT for scheduled email reminders.

Imagine this scenario: Your client requests a solution to send Time Card reminder emails to employees at three different intervals based on the Week Ending Date. The challenge? Each reminder email is only sent out on specific calculated dates based on the Week Ending Date that comes from a tightly controlled Time Card Period object. Provided below is a screenshot of a sample Time Card record followed by a description of how the reminder fields are calculated.

1. Submit Reminder: Sent 2 days before the Week Ending Date (always a Friday)
2. Unsubmitted Reminder: Sent 2 days after the Week Ending Date (always a Tuesday)
3. Beginning of the Month Reminder: Sent at the beginning of the next month based on the reporting week

Original solution: Three scheduled flows

To meet this requirement, I developed three separate scheduled flows that read Time Card records to determine if the date in the respective formula field matches the current date. If so, a specific reminder email is sent. I’m going to walk through the three main components of the original Submit Reminder Alert scheduled flow to review how the flows are configured.

1. Flow Scheduling — The flow is scheduled to run daily at the specific time that is established when the flow was initially configured via the ‘Set a Schedule’ window.

A few tips regarding scheduled flows:

• The start time is based on your organization's default time zone on the Company Information page (Setup > Company Information).
• Check the Setup > Scheduled Jobs to confirm that the displayed run time is correct.
• If a flow is scheduled to run one time with a date and time that already passed, the flow won’t run.
• It’s the Automated Process user who runs schedule-triggered flows.

2. Submit Reminder Date Decision Element — This shows the Decision element that checks if the Time Card record’s Submit Reminder formula field equals the current date.

3. Send Submit Reminder Email — When the Submit Reminder Date is equal to the current date, the Send Submit Reminder Email action shown below is executed.

A solution to overcome testing challenges

During UAT, testing scheduled flows with date-dependent processing becomes cumbersome, particularly when the testing window is short. Manipulating the referenced Week End Date that controls the formula fields could be employed but this would still require coordination with testers.

As a result, I needed to develop a process that allows testers to control which email reminders are sent based on their schedule and the desired email destination so the tester could confirm the contents of the email sent. To address the testing challenges, I extracted the email sending process from the scheduled flow, let’s call that the ‘parent’ flow, and placed it into a ‘child’ subflow. Let's explore this approach in detail.

Step 1: Create a subflow using the Save As - A New Flow option

In lieu of creating the subflow from scratch, I used the Save as - A New Flow option from the original scheduled flow to create the new subflow named Time Card - Email Subflow. Most importantly, I selected Autolaunched Flow (No Trigger) for the Type field under Advanced settings. This is useful if you originally invested a lot of time building a flow before deciding to make it a subflow. You will get errors that will need to be resolved. For example, the referenced $Record variable doesn’t exist and will need to be replaced. In spite of time spent resolving errors, using Save as - A New Flow can be a time saver — especially if the original flow has a lot of variables that would need to be created from scratch in a brand new flow.

Step 2: Create input variables in the subflow

Setting up input and output variables in the subflow is essential to sending and receiving data between the parent and child flows. Shown below are the input variables that need to be created in the new subflow. Values received in the varEmailAlert input variable from the parent flow are: ‘Reminder’, ‘Unsubmitted’, or ‘Beginning of the Month’.

The varTimeCard input variable will receive the Time Card record from the parent flow.

The varRecipient input variable will receive the email entered by the tester during UAT. This will be covered in the last step.

Step 3: Add a Decision element in the subflow

Next, the Decision elements were added to the subflow to control the processing path based on the varEmailAlert variable. Although not shown below, the respective email actions (one each for each type of email alert) mirrored the actions that were deleted from the original scheduled flows.

The Reminder to Submit Time Card outcome is set to varEmailAlert equals Reminder.

The Unsubmitted Time Card Notice outcome is set to varEmailAlert equals Unsubmitted.

The Beginning of the Month Reminder Outcome is set to varEmailAlert equals Beginning of the Month.

Step 4: Make updates to the parent flow

Now that the subflow is fully configured and activated, I delete the Send Email element from each original scheduled flow. Then, I add new subflow elements in all three flows.

Next, I select the name of the new subflow, then click Done. Note: If your flow does not display, check and make sure you activated the flow, otherwise it won’t show up.

Lastly, I need to set the input values to pass data from the parent flow to the child subflow. In the right panel shown in the example below, 'Reminder' is passed into the varEmailAlert field, and the $Record variable is passed into the varTimeCard field. This data will be used as input for the subflow, resulting in a 'Submit Reminder' email being sent.

Now it’s time to see the final part of the solution. Shown below is a Time Card record page where a test can be initiated by clicking the Test Email Alert button.

By the way, if you’re new to creating an action button, here are a few tips.

• Start from Object Manager in Setup, then select your desired object, which in my case was the Time Card object.
• Click Buttons, Links, and Actions.
• Click the New Action button located in the upper right.
• Choose Action Type = Flow.
• Choose the desired flow from the Flow pick list. NOTE: The flow must be Active or it will not appear in the picklist.
• Enter a Label = Test Email Alert.
• Save the Action.

Following is a screenshot of the configured action button.

• From Object Manager, go to the record page layout to add the action button. The screenshot below shows the Test Email Alert action button added to the Time Card record Lightning page.

Once the button is clicked, the following screen flow opens where the tester can select the email they want to send and the email they want the alert sent to.

Now, let’s check behind the scenes to see how the screen flow is configured in Flow Builder. Next, we will break down how the Time Card Email Alert Test Screen components are configured.

Here’s how the radio buttons are configured on the back end. When Reminder to Submit Time Card is selected, it populates ‘Reminder’ in the {!Email_Alert_Type} screen field that will later be passed to the subflow.

Notice that the Reminder to Submit Time Card radio button is configured by entering it as the Choice Label, but the Choice Value is what is passed to the subflow.

When the Email field on the screen is populated, the value is placed in the Email field.

Later, the Email value is set as an input value. Note that the field name passed is {!Email.value} not just Email.

The Test Time Card Email Alert subflow node is the last node in the screen flow. This is almost identical to the one described above in the scheduled flow. One addition is the Email value that is passed. This represents the email entered by the tester so they can control where the email is sent rather than the default employee email that is normally used.

Last but not least, this is a sample email a tester would receive.

Benefits of this UAT solution

Implementing this UAT workaround solution allows testers to control the timing of email formatting tests without relying on the scheduled flow's runtime. This does not replace end-to-end testing to confirm the scheduled flow runs as designed; it just adds a user-friendly option.

This approach has helped me incrementally configure and debug a solution during the build and makes the UAT process more manageable. So, anytime I work with scheduled flows, I always configure the main processing in a subflow, regardless of complexity.

Resources

• Salesforce Help: Schedule-Triggered Flow Considerations
• Trailhead: Autolaunched and Scheduled Flows
• Salesforce Help: Monitoring Scheduled Jobs
• Salesforce Help: Create a Quick Action for a Flow

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