#recordtriggered — 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

Can You Start With a Decision Inside Your Record-Triggered Flow?

When you build a record-triggered Salesforce flow, you may need to use the decision element to differentiate the path your flow takes based on conditions. Before we dive further into best practices, let’s take a look at what the decision element in flow is and what it does.

Decision Element

Salesforce Flow Decision Element is a logic component used in Flow Builder to route your flow’s path based on specific conditions. Think of it like an “if/else” or “switch” statement in programming—it lets you control what happens next depending on the data or situation.

What It Does: The Decision Element evaluates data from the flow (like record fields, variables, or formulas) and then directs the flow down a specific outcome path depending on which conditions are met.

Key Parts of a Decision Element:

• Label & API Name: A name for easy reference.
• Outcome(s): These are the different paths the flow can take. Each outcome has a Label and Condition.
• Default Outcome – A fallback path if none of the other outcomes match.

Let’s say you have a flow that processes a case. You can use a Decision Element to check the case priority: Outcome 1 will send the case to the Escalation Queue, if Case Priority = High. Outcome 2 will send the case to the Standard Queue If Case Priority = Medium or Low. The Default Outcome will log an error, send a notification or do nothing.

Record-Triggered Flow

A record-triggered flow is a type of Salesforce Flow that automatically runs when a record is created, updated, or deleted. It’s often used to automate tasks like updating related records or sending notifications.

Record-Triggered flows are subject to a popular debate: Experts have varying recommendations on how many record-triggered flows are optimal on a given Salesforce object (e.g. Case).

The best practice recommendation and the anti-pattern definition here will be highly dependent on this approach.

One Record-Triggered Flow or Many on a Single Object?

My recommendation is that you can and should have multiple record-triggered flows on a single object, if you can optimize the start conditions to ensure only a small subset of the record-triggered automation logic is executed for a particular record. If you try to combine all the logic into a single flow, you will not be able to tighten your start element conditions effectively, instead you will resort to using decisions to differentiate paths inside the flow.

Why Starting Your Record-Triggered Flow Can Be an Anti-pattern?

Considering all these factors listed above, using a decision that follows your record-triggered flow start element most likely points to an inefficient design: You use decision outcomes to differentiate business logic, when you could separate these paths into multiple record-triggered flows and add these conditions to the start element.

Let me explain.

You have three record types for the case object representing Hardware, Software and Other. You have a fairly sophisticated record-triggered flow to process new Cases. For the Other record type your flow does not do anything.

If the solution in this case is to use a decision element inside your flow connected to the start element to check the record type, then you should consider separating this record-triggered flow into three different flows.

And if some of the business logic repeats for more than one record type, you should consider leveraging subflows.

Why Is This Design More Efficient?

There is a system overhead associated with starting a flow execution. If you execute your flow and evaluate conditions in the decision element, you already used cloud resources. If you can stop your flow from executing, you won’t use any resources. Start element conditions stop the flow from executing.

Can you achieve this just by tightening your start element conditions and excluding the Other record type? Sure, you can. Is the use case always this straightforward. Not, really. For more complex use cases, it may make sense for you to split your flow into multiple record-triggered flows.

Conclusion

While using a decision right after your start element may make sense in certain situations, it is a potential anti-pattern you should watch for. If this is a flow somebody else built, or you built ages ago, seeing this pattern should prompt you to inspect and reevaluate the design in this flow.

Leveraging multiple record-triggered flows on a single object with the support of flow trigger explorer and the execution order setting can be a very good idea in these situations. If your business logic repeats in your triggered automation, you should consider leveraging subflows for easier maintenance.

This post is part of our Best Practices series! Click HERE to see the rest of the posts.

Explore related content:

A Comparative Look at Flow Decision Elements in Salesforce

How to Use the Action Button Component in Screen Flow

Start Autolaunched Flow Approvals From A Button

Error Screen Message Design in Screen Flows

Salesforce’s record-triggered flows have revolutionized the automation landscape, offering a seamless, declarative approach to triggering business processes from record changes. But as every Salesforce professional knows, business requirements fluctuate, and having the agility to turn this automation on or off swiftly is crucial. Enter Custom Metadata Types, a hidden gem that can serve as an on-off switch for your automation. This post will guide you through using Custom Metadata Types within record-triggered flows to control your Salesforce automation.

Understanding Custom Metadata Types

Before diving in, it’s vital to grasp what Custom Metadata Types (CMDTs) are. CMDTs in Salesforce are similar to custom objects, but they store data that informs the behavior of your org’s processes rather than the data about your business. The beauty of CMDTs is that they allow admins and developers to create highly configurable apps that can be updated without altering code or, in our case, adjusting flows directly.

Why Use CMDTs in Record-Triggered Flows? The primary advantage is adaptability. Business rules change, and you might need to pause certain automations during certain events. Instead of deactivating the entire flow (and later remembering to reactivate it), you can use CMDTs to “switch off” the automation. When you’re ready to resume, switch it back on — all without modifying the flow.

How to Implement the On-Off Switch

Now, let’s explore how to set this up step-by-step:

1. Create a Custom Metadata Type:

• Navigate to Setup, and in the Quick Find box, enter “Custom Metadata Types.”
• Click “New Custom Metadata Type” and give it a label, such as “Flow Switch” (Switch__mdt).
• After creating the CMDT, you must add fields the flow will reference. For instance, create a checkbox field called “All Switch”, “Flow1 Switch”, “Flow2 Switch” etc. (All_Switch__c and Flow1_Switch__c)

2. Add Records to the Custom Metadata Type:

• Once your CMDT is set up, it’s time to create a new record. This record acts as the control setting for your flows. In my case, I named this single record Master.
• All Switch will turn on-off all automation while Flow1 Switch will control only Flow number 1.

3. Adjust Your Record-Triggered Flows:

• Here is the new magic: You don’t need to get your CMDT anymore in flow to use it. You can refer to the values by using the correct syntax in your start element formula conditions and formula resources. The preferred method is to add them to the start element entry formula conditions.
• The syntax you need to use here will depend on your CMDT naming and field labels, but it will look very similar to this:

$CustomMetadata.Switch__mdt.Master.All_Switch__c$CustomMetadata.Switch__mdt.Master.Flow1_Switch__c 

*Please note that Switch_mdt is the label of the CMDT, Master is the label of the single record followed by the field name.

4. Testing Your Setup:

• Thorough testing is crucial. Adjust the CMDT records and observe if the flows behave as expected. They should only proceed when “Is Active” is true and stop when false.

5. Maintenance and Updates:

• When you need to turn a flow on or off, update the checkbox fields in the CMDT record. There’s no need to adjust or deactivate the flows, ensuring your configurations remain intact.

Leveraging Custom Metadata Types to control your record-triggered flows is not just a smart move; it’s a strategic approach to maintain scalable, dynamic, and adaptable Salesforce automation. This method protects the integrity of your flows, reduces the risk of errors during off-and-on transitions, and saves significant admin time. Most importantly, it provides the agility your business needs to adapt to changing requirements with grace and efficiency. So, flip the switch on your record-triggered flows with confidence, knowing that Custom Metadata Types have got you covered!

Recommended offsite reading: Architecting for Flexible Automation Execution

One Big Record-Triggered Flow or Multiple?

Fast Field Updates in Record-Triggered Flows (Winter 22)

Migrate to Flow Best Practices

https://salesforcebreak.com/2023/10/15/using-custom-metadata-types-to-control-record-triggered-flows-without-get/

#Automation #CMDT #Configuration #CustomMetadata #DynamicAutomation #FlowManagement #RecordTriggered #Strategies