#subflow — Public Fediverse posts

One Simple Salesforce Flow Hack That Will Change Your Workflow Forever!

What if I told you that the Flow you’ve been building could secretly hold the key to a much bigger impact in the automation world? A world where you don’t rebuild logic over and over… where one Flow powers multiple flows.

Sounds dramatic, right? But once you learn this trick, it will be an invaluable addition to your flow arsenal that will superpower your workflows going forward.

Let’s start by building this use case. Then we will get to the hack part.

Step 1. Build the Original Record-Triggered Flow

We’ll start with something simple: a record-triggered Flow on Opportunity that creates a Task when the Opportunity hits a certain stage. Check whether there is an open task already with the same subject related to the opportunity, before creating another one. If there is an open task already, skip the create.

• Trigger: Opportunity → when Stage = “Proposal/Quote”
• Action: Create Task → Assigned to Opportunity Owner
• Due date: 7 days from the current date
• WhatId (Related to Id) set as the triggering Opportunity

Straightforward.

But here’s the catch: this logic lives in a record-triggered flow. What if I wanted to leverage the task creation logic for multiple record-triggered flows (including scheduled paths), schedule-triggered flows and possibly for screen flows, as well. In addition, could I leverage the same flow for other object records in addition to opportunities? Good food for thought.

Step 2. Save As an Autolaunched Flow

Here’s where the hack begins.

From the Flow Builder menu, click Save As → choose A New Flow → Autolaunched (No Trigger).

Now we have the same logic, but free from the record trigger.

Step 3. Replace $Record With Input Variables

The Autolaunched Flow still references $Record from the Opportunity. That won’t work anymore. Time to swap those out. The references are listed under Errors. The flow cannot be saved until these Errors are fixed.

• Create Input Variables for everything your logic needs; e.g., recordId (WhatId), OwnerUserIdVar, DelayInDaysVar.

• Update your Create Task, Get Task elements and the Due Date formula to reference those input variables instead of the $Record.

Boom. Your Flow is now a Subflow – it can take in data from anywhere and run its magic.

Step 4. Refactor the Original Record-Triggered Flow

Time to circle back to the original record-triggered Flow.

• Open the Flow, Save As a New Version.

• Delete all the elements. (Yes, all. Feels risky, but trust me.)

• Add a Subflow element.

• Select your new Autolaunched Flow.

• Map the input variables to $Record fields, and provide the delay in days parameter value.

Now, instead of directly creating the Task, your record-triggered Flow just hands $Record data to the Subflow – which does the real work.

Here is how the debug runs works.

Why This Hack Changes Everything

This one move unlocks a whole new way of thinking about Flows:

• Reusability – Logic built once, used anywhere.

• Maintainability – Update the Subflow, and every Flow that calls it stays consistent.

• Scalability – Build a library of Subflows and assemble them like Lego pieces.

• Testing Ease – Some flow types are hard to test. Your autolaunched subflow takes in all the necessary parameters in the debug mode, and rolls back or commits the changes based on your preference.

Suddenly, your automation isn’t a patchwork of disconnected Flows – it’s a modular, scalable system.

The Secret’s Out

I call this the “Save As Subflow” hack. It’s hiding in plain sight, but most builders never use it. Once you do, your workflow will never be the same.

Remember, you can make your subflow logic as flexible as you want. You can add input variables for subject and description. This would make your task creation even more flexible so that it can be used for other objects like Case and Custom objects.

Try it today – and the next time you find yourself rebuilding logic, remember: you don’t have to. Just save it, strip $Record, add input variables, and let your Subflows do the heavy lifting.

Explore related content:

Automate Permissions in Salesforce with User Access Policies

When Your DMLs Have Criteria Conditions Other Than Id

Display Product and Price Book Entry Fields in the Same Flow Data Table

How to Use a Salesforce Action Button to Validate Lookup Fields in Screen Flows

#Hack #HowTo #RecordTriggered #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #Subflow

One Simple Salesforce Flow Hack That Will Change Your Workflow Forever!

What if I told you that the Flow you’ve been building could secretly hold the key to a much bigger impact in the automation world? A world where you don’t rebuild logic over and over… where one Flow powers multiple flows.

Sounds dramatic, right? But once you learn this trick, it will be an invaluable addition to your flow arsenal that will superpower your workflows going forward.

Let’s start by building this use case. Then we will get to the hack part.

Step 1. Build the Original Record-Triggered Flow

We’ll start with something simple: a record-triggered Flow on Opportunity that creates a Task when the Opportunity hits a certain stage. Check whether there is an open task already with the same subject related to the opportunity, before creating another one. If there is an open task already, skip the create.

• Trigger: Opportunity → when Stage = “Proposal/Quote”
• Action: Create Task → Assigned to Opportunity Owner
• Due date: 7 days from the current date
• WhatId (Related to Id) set as the triggering Opportunity

Straightforward.

But here’s the catch: this logic lives in a record-triggered flow. What if I wanted to leverage the task creation logic for multiple record-triggered flows (including scheduled paths), schedule-triggered flows and possibly for screen flows, as well. In addition, could I leverage the same flow for other object records in addition to opportunities? Good food for thought.

Step 2. Save As an Autolaunched Flow

Here’s where the hack begins.

From the Flow Builder menu, click Save As → choose A New Flow → Autolaunched (No Trigger).

Now we have the same logic, but free from the record trigger.

Step 3. Replace $Record With Input Variables

The Autolaunched Flow still references $Record from the Opportunity. That won’t work anymore. Time to swap those out. The references are listed under Errors. The flow cannot be saved until these Errors are fixed.

• Create Input Variables for everything your logic needs; e.g., recordId (WhatId), OwnerUserIdVar, DelayInDaysVar.

• Update your Create Task, Get Task elements and the Due Date formula to reference those input variables instead of the $Record.

Boom. Your Flow is now a Subflow – it can take in data from anywhere and run its magic.

Step 4. Refactor the Original Record-Triggered Flow

Time to circle back to the original record-triggered Flow.

• Open the Flow, Save As a New Version.

• Delete all the elements. (Yes, all. Feels risky, but trust me.)

• Add a Subflow element.

• Select your new Autolaunched Flow.

• Map the input variables to $Record fields, and provide the delay in days parameter value.

Now, instead of directly creating the Task, your record-triggered Flow just hands $Record data to the Subflow – which does the real work.

Here is how the debug runs works.

Why This Hack Changes Everything

This one move unlocks a whole new way of thinking about Flows:

• Reusability – Logic built once, used anywhere.

• Maintainability – Update the Subflow, and every Flow that calls it stays consistent.

• Scalability – Build a library of Subflows and assemble them like Lego pieces.

• Testing Ease – Some flow types are hard to test. Your autolaunched subflow takes in all the necessary parameters in the debug mode, and rolls back or commits the changes based on your preference.

Suddenly, your automation isn’t a patchwork of disconnected Flows – it’s a modular, scalable system.

The Secret’s Out

I call this the “Save As Subflow” hack. It’s hiding in plain sight, but most builders never use it. Once you do, your workflow will never be the same.

Remember, you can make your subflow logic as flexible as you want. You can add input variables for subject and description. This would make your task creation even more flexible so that it can be used for other objects like Case and Custom objects.

Try it today – and the next time you find yourself rebuilding logic, remember: you don’t have to. Just save it, strip $Record, add input variables, and let your Subflows do the heavy lifting.

Explore related content:

Automate Permissions in Salesforce with User Access Policies

When Your DMLs Have Criteria Conditions Other Than Id

Display Product and Price Book Entry Fields in the Same Flow Data Table

How to Use a Salesforce Action Button to Validate Lookup Fields in Screen Flows

#Hack #HowTo #RecordTriggered #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #Subflow

Top 9 Salesforce Winter 25 Flow Features

As we edge closer to the Winter 25 release, it’s the perfect time to explore the new Salesforce Flow features! This release introduces significant updates like the Flow Trigger Explorer and new trigger order functionality. These tools not only simplify the management of complex automations but also provide a more intuitive user experience for Salesforce admins and developers. Let’s unpack some of the new features!

1. Transform Data into More Target Resource Types

In the Transform element, you can now use more target resource data types, such as Text, Numbers, Currency, Boolean, Date, and Date/Time. Previously, the Transform element’s target resource only supported complex data types, such as Record or Apex-defined.

This feature is especially useful when creating a text collection of record Ids.

🚨 Use Case 👉 How The Transform Element Saves You Loops

2. Create or Update Records Efficiently The New Create

You can now use the Create Records element to create or update records based on whether a specified field value exists in the database. The Create Records element makes the process of saving records easier and faster, as you no longer check separately for existing records. By merging create and update into one element, you configure and maintain the flow more easily while reducing potential errors from separate operations.

Create Records with matching record check now supports collections.

🚨 Use Case 👉 Create by Checking a Matching Record in Flow (includes limitations)

3. Email Action: Expand Recipients to 150 Including CC and BCC

This is huge for many Orgs: The maximum total number of recipient email addresses is increased from 5 to 150. The updated action now supports CC and BCC recipients. Any address entered in the CC field receives a copy of the email, and those in the BCC field also receive a copy, but their email addresses are hidden from all recipients.

4. Action Button (Generally Available)

With the Action Button component, the running user can trigger a screen action with the click of a button on a screen. The screen action runs an active autolaunched flow, and the results of the autolaunched flow can be shown on the same screen as the button. This component means fewer screens so users can complete screen flows more quickly and with fewer mistakes. Previously, users clicked through multiple screens to get the same functionality.

🚨 Use Case 👉 How to Use the Action Button Component in Screen Flow

5. Prefill Support For The Repeater Component

Collect User Input to Modify a List of Records from a Screen: You can now use the Repeater component to update existing record collections so it’s easier for end users to change a collection of records in a screen flow. Previously, the Repeater component in the Screen element supported only creating records.

6. Select Multiple Choices with Choice Lookup Component

You can now configure the Choice Lookup component to accept either a single selection or multiple selections (up to 25), making it more flexible for your business processes. Previously, only the Lookup component supported selecting multiple options through a lookup field.

7. Launch Another Prompt Flow as a Subflow In a Prompt Flow

Prompt flows did not support subflows before Winter 25. With this release, the Subflow element is available for prompt flows. You can now break your automation into building blocks and reduce the complexity of a prompt flow. To perform a common task, you can call another reusable prompt flow from within a prompt flow. Prompt flows can use the Subflow element to reference only other prompt flows.

8. See Scheduled Flows Limit in Debug Details

This is a big deal for people who hit this limit before: The schedule-triggered flows in your Org can only process up to 250,000 records within 24 hours. This usage against this limit could not be checked via REST API unlike some of the other flow limits. Now, you can view the maximum number of scheduled flows that your org can run daily, helping you stay under the limits. Previously, the panel showed only the ID of the record on which the debug operation ran and the number of records impacted. This additional information helps you plan and execute more efficiently, avoiding the frustration of halted flows.

9. Various Cool UI Updates

Errors and Warning Pane

The new tabbed Errors and Warnings pane lists issues that prevent you from saving and activating your flow as you work in an easy to scan format. The pane includes links to the Flow Builder canvas that help you identify the source of issues. You can show or hide the new pane with the Show Error button, which includes a notification badge that displays the total number of issues to address.

Flow Save Button Gets An Update

New design for Save As Button: The default action is Save As New Version. Right side chevron icon menu will take you to the Save As New Flow choice.

Flow Tips For Best Practices

New best practice tips in Flow Builder help you identify designs that can slow down your flows and increase the risk of reaching Apex governor limits. These tips appear in the Flow Builder canvas and provide guidance on how to improve your flow. By addressing these suggestions, you can ensure that your flows are running efficiently and avoid potential performance issues.

Deselect Data Table Rows When in Single-Row Selection Mode

This update is especially useful when you allow your user to go back to a Data Table in flow: Running users can deselect a row in a Data Table component that’s set to single-row selection mode, because we now use checkboxes instead of radio buttons to select or deselect rows. To return to the previous functionality and use radio buttons, in the row configuration section, select Require User to Make a Selection.

Find Flow Child Resources More Easily

This is a huge timesaver: When referencing the child resource of an element in a flow, such as a screen component within a Screen element, now you can search for and select it directly in the updated resource menu. Previously, you had to first select the element of the child resource, and then select the child resource. This change applies to these child resources: Screen components, screen actions, Decision element outcomes, and Wait element configurations.

Additional Notes

Restrict User Access to Run Flows (Release Update)

This is a very important update that is coming in the near future. I wanted to draw your attention to it, as it’s best we prepare for it early. Salesforce restricts a user’s ability to run a flow with this update enabled. A user must be granted the correct profile or permission set to run the flow. When enabled, this release update deprecates the FlowSites org permission, which gave all users in the org access to run any flow. With this update, flows run more securely because only users who are granted correct profiles or permission sets can run flows. This update was postponed the enforcement date to Winter 26.

Enable EmailSimple Invocable Action to Respect Organization-Wide Profile Settings (Release Update)

The Send Email invocable action adheres to organization-wide email address profile settings with this update enabled. This update was first made available in Summer 23 and was scheduled to be enforced in Spring 24, but we postponed the enforcement date to Winter 25.

Enforce Sharing Rules when Apex Launches a Flow (only for API v. 62.0)

This versioned update enforces sharing rules when an Apex class that’s declared using the with sharing keyword launches an autolaunched flow that runs in the default context. To enforce sharing, the Apex class must be declared using the with sharing keyword.
Previously, the flow ran in system context without sharing even when an Apex class was declared using the with sharing keyword launched the flow.

Einstein functionality received a few updates in flow, but they are all in beta for this release.

Enjoy

Explore related content:

Top 7 Salesforce Spring 25 Flow Features

How to Use the Action Button Component in Screen Flow

Create by Checking a Matching Record in Flow

Top 12 Salesforce Summer 24 Flow Features

Winter 23 Flow Formula Syntax Check

#ActionButton #Apex #Data #Email #Features #Lookup #NewRelease #Salesforce #Subflow #Update #UseCases #Winter25

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