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

Is Your Salesforce Flow Too Big?

When building complex business processes into Salesforce flows, it’s easy for them to become too big, making them harder to manage and maintain. To avoid issues with your long flows, adopting modular development principles can help improve your flows. Modular development breaks down large flows into smaller, manageable components that are easier to test, maintain, and update. In this post, we’ll explore strategies like using subflows and splitting flows to improve your flow’s scalability, performance, and readability.

How do you know your flow is too big?

Some symptoms are:

1. UI: You need to scroll your canvas too frequently to navigate your flow.

2. Testing: Your debug log is too long. Testing your flow with full coverage becomes very difficult.

3. Readability: When debugging and making changes, it takes a long time to locate an element related to a certain step. Your resource and element lists get too big.

4. Performance: Loading and saving your flow takes a long time. Depending on your particular Salesforce flow type, this could also affect execution performance.

Flows are low-code development tools. You can leverage many of the best practices of code development when building flows. One of these best practices is modular development.

Modular Development

Modular code development is a software development approach that involves breaking down a program into smaller, self-contained, and reusable components, called modules. Each module is designed to perform a specific task or function and can be independently developed, tested, and maintained.

Key Characteristics of Modular Code

Benefits of Modular Code Development

Read Jen W. Lee’s Embrace Modular Flows to Build Smarter Automation for Agentforce post linked below this article for modular flow examples.

What to Do When Your Flow is Too Big

There are two strategies that help you improve your low code design when your flow gets too big:

• Subflows: Subflows are flows that are called from other flows. They can receive input variable values, and return output variable values to the parent flow.
• Splitting flows: For record-triggered flows, subflows may not be the most effective solution in some cases. Before-save record-triggered flows do not support subflows. Even for after-save flows, splitting your flow into multiple flows could bring you better overall system execution performance than using subflows.

Subflows

Subflows are either autolaunched flows or screen flows. Autolaunched flows can be subflows for any flow type that supports subflows. Screen subflows can only be subflows for another screen flow because it is the only flow type that supports the screen element.

You can use subflows for the reasons mentioned earlier in this article, but more importantly, I recommend that you use them whenever you have logic that repeats in your Org’s low code. You don’t want to repeat the same logic in multiple places in your Org, because keeping track of where this is used can be a nightmare. When the logic changes, you will have to make changes in multiple places, debug, test, and deploy multiple flows.

When working with subflows, it’s easy to identify the subflow in the parent flow. The subflow element links directly to the subflow, allowing you to open and review it in the canvas.

When you see a subflow in your Salesforce flow list view, you cannot identify where this subflow is called from. This is a challenge. Use clear naming conventions, and document dependencies in your description. Your description is searchable in the new Automation Lightning App list views.

Splitting Flows

A big flow with subflows still brings complexity to your low-code maintenance. If you have a big screen flow, that fulfills multiple missions, you should consider splitting the flow into multiple flows and having the user launch them separately.

But splitting flows becomes even more important when dealing with record-triggered flows. First of all, This is the only strategy that you can leverage when dealing with before-save flows. Subflows are not supported for before-save.

For after-save flows, you need to remember that your flow will execute every time your flow entry conditions evaluate true. When you have complex business processes built on the back of a high-volume standard object like Opportunity or Case, it becomes a difficult task to tighten your start element conditions so that your flow does not execute every time. When your flow executes it will go through most of the elements in the canvas, potentially also through decision elements, consuming valuable resources. If you don’t pay attention to your consumption against the execution governor’s limits, you could also cause a fault.

In these scenarios, splitting your complex logic into multiple record-triggered flows can improve overall system optimization. Start by reviewing your large flow and focusing on the decision elements. These are key areas where splitting the flow will be most effective. For each outcome path, consider creating separate flows. The entry criteria for these new flows should be based on the decision outcomes from your main flow. This approach will help ensure that some of the new record-triggered flows don’t execute in certain scenarios, thereby improving system performance.

Managing Multiple Record-Triggered Flows with the Flow Trigger Explorer

When you have multiple record-triggered flows on the same object, you have two challenges:

• Finding and managing record-triggered flows
• Adjusting the execution order of record-triggered flows

Flow Trigger Explorer addresses these two challenges very well.

Go to this tool either by clicking the button on your Flow Setup page, or by clicking the link in your record-triggered flow start element.

Once you adjust the pulldowns to select the object, you can view your flows on the object and adjust the execution order of record-triggered flows. To learn more about the flow trigger explorer read this page.

Conclusion

In conclusion, when dealing with large and complex flows, modular development principles are essential to ensure maintainability, scalability, and performance. Strategies like leveraging subflows and splitting flows enable you to simplify design, reduce redundancy, and optimize system resources. By using tools like Salesforce Flow Trigger Explorer and adopting clear naming conventions and documentation practices, you can manage dependencies and execution order effectively. Embracing these best practices ensures that your Salesforce automation remains efficient, readable, and adaptable as your business processes evolve.

This post is the 3rd installment in our Best Practices series, offering key insights for optimizing your Salesforce flow. Read the other posts in the series here 👇🏼

Can You After-Save When You Can Before-Save?

Can You Use DML or SOQL Inside the Loop?

Embrace Modular Flows to Build Smarter Automation for Agentforce (Salesforce Admins)

#Apex #FlowTriggerExplorer #LowCode #ModularDevelopment #NoCode #Salesforce #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

Exploring Subflows: When and How to Use Them

Hello folks,

Spring 22 is approaching fast. The release notes are out, and there are a bunch of exciting flows coming for flows. Let’s dive into those in the next issue of the newsletter, though. I will write about Salesforce subflows today.

Exciting News: Recognition as a Salesforce Influencer

But before I dive right in, I need to tell you about something quite extraordinary that happened to me this past week: Salesforce Ben, one of the most popular publications about Salesforce, published a post that listed the top 20 Salesforce influencers for Salesforce, and to my surprise, I happen to be one of them. I heard something like this was coming, but I did not expect to be on a list of 20. I thought if they made a list of 50 folks to follow over 50, then I’d be on it. Thanks for all your support. I am grateful. You can find the full list here.

Understanding Subflows

Subflows are not for everyone. They have their place in the flow architecture, and they are helpful, but there are many misconceptions around them. What they should not be used for, in my humble opinion, is as follows:

• To get a fresh empty canvas to organize your flow better.
• To bring all the logic for all the record-triggered flows together for one single object.
• To circumvent governor limits, e.g., force a separate transaction.

The Concept of Subflows in Programming

The concept of subflows is not new in the programming world. In programming, you can have various different code logic executing the same code in multiple places. What you would typically do in that case is that you’d separate out this piece of code and call it from within your code whenever it is needed. In summary, good reasons to use subflows are:

• Have a need to repeat the same logic within various flows.
• Flow logic is expected to be revised over time.
• Ease of maintenance.

What are Salesforce subflows?

Salesforce subflows can be autolaunched, or screen flows. Screen subflows can be called from screen flows. Autolaunched subflows can be called by every other flow type with the exception of before-save record-triggered flows (a.k.a. fast field updates, and this may change in the coming releases).

There is no setting that makes a subflow a subflow; they are essentially flows that you call from within another flow by inserting the subflow element.

For an active flow to work without problems, the subflows need to be activated as well.

Unless forced to execute in a different context, subflows will run in the same context that your main flow runs in: user, system, or system without sharing.

To understand better what a subflow is, you can think of them as aliases that call another sequence of logic that will be pasted into your main flow when it runs, and the whole logic will be executed as a whole.

Subflow Parameters

Subflows often have input and output parameters. The way you set this up is like any other autolaunched or screen flow: You check input and/or output checkboxes when you set up your variables.

Examples of Subflow Use Cases

Let me give you two examples:

• Address entry screen subflow: You may have certain custom checks, validations, and error messages that you need to set up whenever the user enters an address. In most cases, you will have many different flows, sometimes the same flow in two different locations calling for an address entry. You can create an address entry subflow and pass the values back to your main flow after the user enters them correctly.
• Average Duration Calculation Subflow: You may need to calculate the time it took for your organization to close cases on all cases under one single account and take an average of the duration. If you need to do this multiple times in multiple flows, it may be a good idea to build this as a subflow. You can pass the accountId to your subflow and get back an average duration number back that you can use in your main flow.

Common Misconceptions about Subflows

Let’s go back to my original bullet points of wrong reasons for using Salesforce subflows, and play Mythbusters:

• Fresh empty canvas: Unless you plan to use your subflow multiple times in different flows, subflows do not give you simplicity; they may increase complexity.
• One giant record-triggered flow: This means you will do everything after-save. The outcome will be one giant flow with subflows, potentially less performant and harder to maintain. Salesforce is giving us tools to manage multiple Record-Triggered flows on one object. More on that will come in next week’s issue.
• Governors limits: This is an interesting one. Louder for the ones in the back: Subflows do not force a separate transaction. Main flow and all subflows execute in one single transaction. There is literally nothing that helps you beat governors limits when using subflows.

Now that I got that off my chest, let me give you a few links.

Recently published content:

• I posted a list of all the Salesforce blogs I follow. Please read it here.
• I published a short video that includes a sneak peek into Spring 22 flow features. You can watch that here.

Enjoy your flow learning journey.

Explore related content:

How To Use Subflows On Fault Paths

Can You After-Save When You Can Before-Save?

Salesforce Flow Best Practices

Salesforce Platform Admin Certification: Navigating the 2025 Changes