#schedule-triggered — Public Fediverse posts

Can You Start With a Loop Inside Your Schedule-Triggered Flow?

Salesforce automatically runs schedule-triggered flows at specific times and intervals without needing user interaction. These flows are ideal for tasks that need to occur on a recurring basis, such as daily data updates, batch record processing, or sending scheduled notifications. By configuring the start time, frequency (daily, weekly, etc.), and conditions for triggering, admins can efficiently manage routine operations, ensuring data consistency and reducing manual workload. Schedule-triggered flows help streamline business processes and maintain system accuracy by automating time-based actions.

There are three common misconceptions about schedule-triggered flows

1. New schedule-triggered flow builders usually think they must get all the records their flow needs to process, loop, and process all records in a single flow interview. In other words they need to bulk-process their flow logic themselves at the time of build. I will show you below, that this assumption is incorrect.
2. New flow learners have a hard time understanding how their start time is scheduled. When should they use a schedule-triggered flow versus a scheduled path in a record-triggered flow? I will explain how you can correctly decide in this article.
3. Most flow builders assume that schedule-triggered flows require an object selection in the start element. Later in this article, I’ll demonstrate how schedule-triggered flows can be designed to run at a specific future time, automating processes that aren’t necessarily tied to records of a particular object defined in the start element.

Get and Loop Elements Right After the Start Element Anti-Pattern

When building a schedule-triggered flow, you select an object in the start element and optionally add conditions. Here’s a metaphor to explain: Imagine you want your flow to run next Saturday at midnight and update all cards with a face value of 3 to 13. In a deck, there are 4 such cards. Your logic only needs to handle one record (one card). The flow engine automatically creates separate interviews for each matching record (all 4 cards), processing them without manual loops or retrieval. This means all 4 cards are updated efficiently, with the flow engine handling bulk processing for you. No extra logic is needed—just define the criteria, and the engine does the rest.

Let’s return to Salesforce and discuss how schedule-triggered flows are executed. Suppose you want to process all Contact records in your org where the Title is ‘Director’ and update it to ‘Senior Director.’

Here’s how you’d set it up:

1. Configure the start element to run on the Contact object.

2. Add a condition to the start element to filter records where the Title equals ‘Director.’

3. Add an update element to change the Title from ‘Director’ to ‘Senior Director.’

When the flow runs at the specified date and time, the flow engine processes each matching record individually. For example, if there are 4 matching records, the engine will execute 4 separate flow interviews, one for each record. These interviews are batched, with each batch containing up to 200 interviews (or records). So, for 4 records, the flow executes in a single transaction, while for 201 records, it would execute in 2 transactions.

Avoiding Common Pitfalls: Why You Shouldn’t Manually Loop Through Records in Schedule-Triggered Flows

What new learners tend to do is configure the start element, then proceed to get all contacts in the org where the title is Director, loop through them and process them. If there are 4 matches in the Org, this multiplies the update execution need and produces inaccurate results. Your single interview will run 4 loops, executing on 4 matching records and producing 4 interviews. That is actually 16 executed loops that are needed.

In summary, you build your flow to handle a single record, set up your start element to define which records the flow need to run on, and don’t worry about the rest, the flow engine will take care of it.

Schedule-Triggered vs. Scheduled Path in Record-Triggered Flow

While there are overlaps, the usage of schedule-triggered flows are different in nature than the scheduled path under record-triggered flow. Here are the parameters that need to be considered:

• When you have a specific date and time you need your flow to execute – e.g. next Thursday at 11:00 PM – then you must use a schedule-triggered flow.
• When you have a frequency requirement for recurring actions, then you must build a schedule-triggered flow.
• When you need to relate your execution time – 1 hour after or 1 day before – to a record being created or updated (DML), then you must use a scheduled path in a record-triggered flow. Remember though: you cannot determine the time of the action for offsets longer than a day. If you have an email action and a 1-day after offset, the system will send the email at the same time the create/update occurred one day later.

Certain situations can generate approximately the same outcome using either solution. This is generally a confusing topic when you first start diving into time delay operations using flow.

Object Selection

You may have noticed, the Object reference in the start element of the schedule-triggered flow is marked as optional. Most people never try this alternative. When you build a schedule-triggered flow without an object selection, you create a scheduled job to run in the future. This flow, as opposed to the other flows with object selection, will for sure run only one transaction containing one single flow interview. Therefore this is a flow that can include loops and collections. Having a loop at the start of this type of flow is not an anti-pattern. Remember that you can use the transform element, collection filter and sort to lighten the load when you deal with collections.

🚨 Use case 👉🏼 Streamlining Operational KPI and Trendlines for Optimization

Conclusion

The power of scheduled jobs in Salesforce lies in their ability to automate time-dependent tasks, ensuring consistency, efficiency, and reliability across business processes. By utilizing scheduled jobs—whether through schedule-triggered flows, Apex schedulers, or declarative tools—organizations can automate repetitive tasks like data cleanups, report generation, and batch processing without manual intervention. This not only saves time and reduces errors but also ensures that critical processes run during off-peak hours, optimizing system performance. Scheduled jobs also enhance scalability, allowing businesses to handle large data volumes and complex workflows with minimal oversight.

Using schedule-triggered flows make scheduled jobs more accessible to most profiles on the Salesforce platform. It is sometimes better to handle some actions after hours while the Org usage is down to avoid potential system performance issues. Flow builders should always consider this tool to produce the automations that will enhance the company KPIs and goal attainment performance.

Explore related content:

Salesforce Flow Best Practices

How To Use Custom Permissions In Salesforce Flow

One Big Record-Triggered Flow or Multiple?

Understand How Scheduled Flows Affect Governor Limits (External)

Time Zone and Time Operations in Flow

Streamlining Operational KPI and Trendlines for Optimization

In the fast-paced world of nonprofit organizations, optimizing operational efficiency is paramount. Recently, I had the opportunity to assist a client facing a common challenge: consolidating service records scattered across multiple Salesforce objects to generate comprehensive historical trends for their operational Key Performance Indicators (KPI). To tackle this task effectively, I devised a solution centered around leveraging the power of scheduled and autolaunched flows within Salesforce.

Understanding the Challenge

My client’s service records were stored in two distinct Salesforce objects: Support records and Service Delivery records. To derive meaningful insights and track performance over time, it was imperative to aggregate data from these disparate sources into a unified format.

Solution Overview

To address this challenge, I devised a robust solution leveraging autolaunched flows operating as sub-flows under a schedule-triggered flow. This approach allowed for seamless integration and automation of the data consolidation process.

The solution consists of three main components:

• Service Summary Record Custom object
• Autolaunched flow (subflow)
• Schedule-triggered flow

Service Summary Record Custom Object

Upon deliberation with the nonprofit customer, I planned on creating one monthly record for each client served.

This record would aggregate all the service details for the client.

See the image below for the field list of the object.

This object record would be created based on two records the nonprofit organization used in the past five years.

Support Record

Service Delivery Record

Autolaunched Flow (Subflow)

It is important to note that I attempted to do this a few years ago without success because, at the time, we had the famous “too many iterations” error in effect that prevented me from executing more than 2,000 elements in one flow run. However, the autolaunched flow, equipped with input parameters including Contact, Start Date, End Date, and a checkbox determining whether the contact should be updated, systematically processed service records for each client.

I optimized the flow several times to ensure that the extensive processing did not violate the governor limits, returning the Apex CPU error.

The final design was executed without errors, processing a full year’s data.

See the images below for the high-level flow build design.

In addition to aggregating historical trends, the flow provided the functionality to update contact records as needed, ensuring audit capabilities. Therefore, I decided not to use this option so as not to burden the system resources further.

Schedule-Triggered Flow

I set up a schedule-triggered flow that calls the autolaunched flow as a subflow to process the historical records. I executed and processed all the past data triggering the schedule-triggered flow manually. The schedule-triggered flow now runs on the first day of the month to process all records from the previous month.

Final Thoughts

By harnessing the capabilities of schedule-triggered and autolaunched flows within Salesforce, I successfully streamlined the process of generating operational KPI trends for my client. Consequently, this approach not only optimized workflow efficiency but also empowered the organization with actionable insights to drive informed decision-making.

In conclusion, combining schedule-triggered and autolaunched flows offers a strong method for data consolidation and insight gathering in Salesforce. Moreover, as data-driven decision-making becomes increasingly crucial, using automation tools like these flows is key to boosting efficiency and meeting strategic goals.

Finally, stay tuned for more insights and best practices in Salesforce automation as I continue to explore innovative solutions to common business challenges.

Explore related content:

Hidden Gem in Spring 23: Schedule-Triggered Flow Improvements

Scheduled Flows: Sometimes Later Is Better

Streamline Task Execution with Task and KPI Sequencing

Popular Validation Rules for Salesforce Flows including Phone, Email and Address Fields

Edited by Meredith Anglin.

#Autolaunched #Automation #DataConsolidation #Flow #KPI #Reporting #Salesforce #ScheduleTriggered #Subflow #WorkflowEfficiency

Scheduled Flows: Sometimes Later Is Better

You go through life, and it sometimes feels like drinking from a firehose. This is also through for systems. The current work can overwhelm the available resources. Salesforce Scheduled (a.k.a. Schedule-Triggered) flows are an excellent way to defer some of the work and give your system resources a breather. I discussed this solution this past weekend in Minneapolis at Midwest Dreamin’ but needed more time to go into a step-by-step tutorial. Let me describe the use case and the solution in detail here.

Use case:

You need to track key performance indicators for your operation daily and build a history. Out-of-the-box reporting functionality and report snapshots are not powerful enough for you. In addition, you want to perform sophisticated mathematical calculations and expand your solution in the future to include details from related object records as well. You want to leverage something other than rollups as the value of a rollup field changes dynamically. In conclusion, you decided to track these KPIs for cases daily:

• Count of Created: Created in the previous 24 hours.
• Count of Modified: Modified in the previous 24 hours.
• Count of Open: Count of open cases at midnight.
• Count of Closed on Date: Closed in the previous 24 hours
• Max Wait Open in Hrs: Max Wait on the oldest open case at midnight.
• Average Wait Open in Hrs: Average Wait of all open cases at midnight.

The solution has two essential components:

1) A custom object record that tracks the results

2) A schedule-triggered flow that creates a single record every night

Let me show you:

1) See the screenshot below to review all the Daily Summary Record custom object fields.

You will create this custom object to house the resulting values.

2) Flow solution: The flow solution is a very efficient one. Many don’t know that selecting an object is optional in schedule-triggered flow. For this use case, you will use a flow without an object that gets all the case records in the org. If you don’t have more than 50K cases, you won’t have a problem with governor limits. If you know you will get more than 50K cases, we will have to split this flow into several flows and/or perform multiple targeted gets. You will leverage collection filters and need only one single get.

See the screenshot below to review all the elements in this flow (click to see a larger image).

You will create the elements as follows:

• Start element: Scheduled daily at midnight: No object and no criteria.
• Get the previous daily summary record: This is only necessary to get the created date to filter cases processed since the last run.
• Get all cases in the Org by ascending Created Date order.
• Collection filter 1: Filter for created cases since the last run.
• Collection filter 2: Filter for modified cases since the last run.
• Collection filter 3: Filter for closed cases since the last run.
• Assignment 1: Assign the counts of the collections to variables.
• Filter Open Cases
• Loop Open Cases
• Assignment 2: Add 1 to the counter, calculate case wait, and add to the total wait variable
• If this is the first iteration, capture the current wait as the max wait. This works because our get is sorted (see above).
• Create one single Daily Summary Record.

Now you can accumulate this information in your Org as long as you want for reporting and audit purposes. This is a very elan record that won’t consume significant storage.

Enjoy

Explore related content:

Dynamic Prefill for Salesforce Jotform Integration

Dynamically Create Documents Using PDF Butler

How to Use the Action Button Component in Screen Flow

#Salesforce #ScheduleTriggered #Scheduled