The Ultimate Guide to the Salesforce Screen Flow File Preview Component

The Spring ’26 Release introduced the File Preview Screen Flow Component. This native tool allows Admins to embed document viewing directly into the flow of work. In this post, we’ll explore the technical requirements, real-world observations, and the strategic implications of this functionality.

Beyond the “Files” Tab: Why This Matters

Historically, viewing a file in Salesforce required navigating to the “Files” related list, clicking the file, and waiting for the standard previewer to launch in a separate overlay. If you were in the middle of a Screen Flow, perhaps a guided survey or a lead conversion process, leaving that flow to check a document meant breaking your concentration.

Salesforce introduced a file thumbnail preview that shows visually what is in the file without having to click into it. Please note that the thumbnails show beautifully in the Single Related List component for lightning record pages. In the multiple related list view, I did not see the thumbnails.

In addition to the lightning record page and related list functionality, Salesforce introduced a file preview component that allows the user to see the preview of the file they have just uploaded, or they find attached to an object record in Salesforce.

Technical Blueprint: Configuring the Component

Setting up this component requires a shift in how Admins think about file data. Files data model is unique. To make the component work, you need to navigate the relationship between ContentDocumentLink, ContentDocument, and ContentVersion.

Core Attribute Requirements

 When you drag the File Preview component onto a screen in Flow Builder, you must configure the following:

• Content Document ID (Required): This is the most critical field. The component needs the unique 18-character ID of the ContentDocument record. It will not accept the ContentVersion ID (which represents a specific iteration) or the Attachment ID (the legacy file format). Please note: the preview component always shows the latest version of the file.

• Label: This attribute allows you to provide instructions above the preview window. This is highly effective for compliance-heavy roles, where the label can say: “Verify that the signature on this ID matches the physical application.”

• API Name: The unique identifier for the element within your flow logic, following standard alphanumeric naming conventions.

Using Conditional Visibility

Because the preview window takes up significant screen real estate, it should not be set to “Always Display”, if it will be driven by a data table reactively. Salesforce allows you to specify logic that determines when the component appears. You can set it to display only if a specific file type is selected in the collection and hide the component if the ContentDocumentID variable is null to avoid showing an empty box.

Lessons from the Field: Our “Around the Block” Test

In our recent hands-on testing, we put the component through its paces to see where it shines and where its boundaries lie.

[youtube https://www.youtube.com/watch?v=_k3F2eX4rdM?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent&w=640&h=360]

The File Extension

The previewer is highly dependent on the browser’s ability to interpret file headers and extensions. During our test, we uploaded a standard log file. While the content was technically plain text, the file had a .log extension. The component struggled to render this because it didn’t recognize it as a standard format. However, once we switched to a .txt extension, the preview was crisp and readable. The admin takeaway here is that if your business process involves non-standard file types, you may need to implement a naming convention to ensure files are saved in formats the previewer can handle: primarily .pdf, .jpg, .png, and .txt.

Real-World Use Case

How can you use this component in a live production environment? Here is a scenario where the File Preview component adds immediate value:

Imagine a customer service representative handling a shipping insurance claim. The customer has uploaded a photo of a broken item. Instead of the agent navigating to the “Files” tab, the Screen Flow surfaces the photo on the “Review Claim” screen. The agent sees the damage, verifies the details, and clicks “Approve” all on one page.

Conclusion: A New Era of Flow

The File Preview component represents Salesforce being a holistic workspace. By integrating document viewing into the automation engine of Flow, Salesforce has empowered Admins to build tools that feel like custom-coded applications without writing a single line of Apex. As we saw in our testing, the component is robust and user-friendly. Most importantly, it keeps users focused. Whether you are streamlining an approval process or simplifying a complex data entry task, the ability to see what you are working on without leaving the screen is *chef’s kiss.*

Explore related content:

What’s New With Salesforce’s Agentblazer Status in 2026

Add Salesforce Files and Attachments to Multiple Related Lists On Content Document Trigger

Profiles and Permissions in Salesforce: The Simple Guide for Admins

Salesforce Spring ’26 Brings Major Debug Improvements to Flow Builder

If you’ve been building flows for any length of time, you already know this: a lot of the real work and time goes into debugging. It’s re-running the same automation over and over. Swapping out record IDs. Resetting input values. Clicking Debug, making a small change, saving, and sometimes starting the whole setup again. That loop is where Flow builders spend a lot of their time, especially once flows get even moderately complex.

Salesforce’s Spring ’26 release finally takes aim at that reality. Instead of piling on new features, this update focuses on removing friction from the debugging experience itself. The result is a Flow Builder that feels faster, less disruptive, and much closer to a modern development environment.

Debug Sessions That Don’t Forget Everything

One of the most impactful improvements in Spring ’26 is also one of the simplest: Flow Builder now remembers your debug configuration while you’re actively editing a flow. When you debug a flow, make a change, and save, Salesforce preserves the triggering record you used, your debug options, and your input variable values. That means no more losing your setup every time you click Save, no more re-pasting record IDs, and no more rebuilding your test scenario from scratch.

Your debug session stays intact until you refresh your browser, close Flow Builder, or manually click Reset Debug Settings. This is a big quality-of-life upgrade, especially if you work with record-triggered flows that have edge cases, complex decision logic, multi-screen flows with test data, or anything that requires several small iterations to get right. The practical impact is simple: you can now fix, save, and re-run flows much faster, without constantly breaking your momentum.

Flow Tests Are No Longer “Latest Version Only”

Spring ’26 also changes how flow tests work behind the scenes.

Previously, flow tests were tied only to the latest version of a flow. As soon as you created a new version, older tests were essentially left behind. If a test no longer applied, you deleted it. If it still applied, you recreated it. Now, tests can be associated with specific flow versions.

You can now reuse the same test across multiple flow versions or limit it to only the versions it truly belongs to, and when you create a new version, Salesforce automatically carries those tests forward from the version you cloned. This gives you much tighter control over scenarios like preserving regression tests for older logic, maintaining multiple supported versions, validating breaking changes, and keeping historical test coverage intact. Instead of treating tests as disposable, they become part of your flow’s lifecycle. This is a foundational shift for teams building mission-critical automation.

Compare Screen Flow Versions to See What Changed

Salesforce has had version comparison in other areas of the platform, but Spring ’26 brings it to screen flows. You can now compare any two versions of a screen flow and instantly see what changed across elements, resources, fields, components, properties, and styles.

This makes it much easier to answer the first question most debugging starts with: what changed? Instead of manually opening versions side by side, you get a clear view of differences, helping you pinpoint where issues may have been introduced and focus your testing where it actually matters.

More Control When Debugging Approvals and Orchestrations

Debugging long approval chains or orchestrations has always been painful. You’d often have to run the entire thing just to test one step. Spring ’26 introduces several upgrades that make this far more surgical.

Complete work items directly in Flow Builder

You can now complete orchestration and approval work items without leaving Flow Builder.

While debugging, interactive steps can be opened directly on the canvas. Once completed, the orchestration or approval process resumes immediately.

This keeps the entire test cycle inside the builder instead of bouncing between apps, emails, and work queues.

Debug only the part you care about

You can now define a start point, an end point, or both when debugging orchestration and approval flows, which gives you much more control over what actually runs. Instead of being forced to execute the entire automation, you can skip earlier stages, stop before downstream logic, isolate a single phase, or focus on one problematic section. When you skip steps, you can also provide test inputs to simulate outputs from earlier stages. In other words, you no longer have to run the whole machine just to test one gear.

Selectively control which steps execute

Salesforce has expanded test output controls beyond rollback mode.

You can now decide which orchestration or approval steps should run while debugging, and which should be skipped, directly from the new Configure Test Output experience.

This makes it much easier to validate edge cases, exception handling, and conditional behavior without unnecessary noise.

Smarter Debugging for More Advanced Flow Types

Spring ’26 also delivers improvements for more specialized use cases.

Segment-Triggered Flows: Testing multiple records at once

For segment-triggered flows, you can now debug up to ten records at the same time instead of testing one record after another. You can select multiple segment members, run the debugger, and cycle through each result to see exactly how different records move through your flow.

The canvas highlights the active path for the selected record, and you can filter results by successes or failures, making it much easier to spot inconsistencies. This is especially useful when validating logic across different customer types, messy or incomplete data, and edge cases that would normally take many separate test runs to uncover.

Why This Release Actually Matters

It’s easy to skim release notes and see “debug improvements” as minor polish, but debugging speed directly affects how confidently people build automation, how complex flows can realistically become, how quickly teams can ship fixes, and how much risk is involved in every change.

With these changes, you can rerun the same scenarios without constantly rebuilding your debug setup, test individual flow versions with far more precision, and isolate only the parts of your logic you actually care about. You can walk through approvals and orchestrations directly inside Flow Builder instead of jumping between tools, and even validate how a flow behaves across multiple records in a single debug run. This is the kind of release that changes how Flow Builder feels to use.

Conclusion

Salesforce has spent the last few releases expanding what Flow can do, and Spring ’26 is about improving how Flow is built. Persistent debug sessions, version-aware tests, selective execution, in-builder work items, and targeted debugging all point in the same direction. Flow Builder is evolving from a configuration tool into a true development environment.

If you build anything non-trivial in Flow, these changes will save you time immediately. And if you teach, support, or scale Flow across teams, they open the door to far better testing practices going forward.

Explore related content:

Top Spring ’26 Salesforce Flow Features

Add Salesforce Files and Attachments to Multiple Related Lists On Content Document Trigger

Spring ’26 Release Notes: Highlights for Admins and Developers

Add Salesforce Files and Attachments to Multiple Related Lists On Content Document Trigger

Flow builders, rejoice! Now with the Spring 26 Release you can trigger your flow automations on ContentDocument and ContentVersion Flow objects for Files and Attachments. Salesforce had delivered a new event type in the previous release that supported flow triggers for standard object files and attachments. The functionality was limited. In this release, Salesforce gave us the ability to trigger on all new files/attachments and their updates for all objects.

You could easily expand this use case to add additional sharing to the uploaded file, which is also a common pain point in many organizations. I will leave out this use case for now which you can easily explore by expanding the functionality of this flow.

Objects that are involved when you upload a file

In Salesforce, three objects work together to manage files: ContentDocument, ContentVersion and ContentDocumentLink.

Think of them as a hierarchy that separates the file record, the actual data, and the location where it is shared. The definition for these three core objects are:

ContentDocument: Represents the “shell” or the permanent ID of a file. It doesn’t store the data itself but acts as a parent container that remains constant even if you upload new versions.
ContentVersion: This is where the actual file data (the “meat”) lives. Every time you upload a new version of a file, a new ContentVersion record is created. It tracks the size, extension, and the binary data.
ContentDocumentLink: This is a junction object that links a file to other records (like an Account, Opportunity, or Case) or users. It defines who can see the file and what their permissions are.

Object Relationships:

The relationship is structured to allow for version control and many-to-many sharing:
ContentDocument > ContentVersion: One-to-Many. One document can have many versions, but only one is the “Latest Published Version.
ContentDocument > ContentDocumentLink: One-to-Many. One document can be linked to many different records or users simultaneously.

ContentDocumentLink is a junction object that does not allow duplicates. If you attempt to create the relationship between a linked entity and the content document when it already exists, your attempt will fail.

What happens when a file is uploaded to the files related list under an object?

Salesforce creates the ContentDocument and ContentVersion records. Salesforce will also create the necessary ContentDocumentLink records; often one for the object record relationship, one for the user who uploaded the file.

For each new file (not a new version of the same file) a new ContentDocument record will be created. You can trigger your automation based on this record being created, and then create additional ContentDocumentLink records to expand relationships and sharing.

Building Blocks of the Content Document Triggered Automation

For this use case I used a custom object named Staging Record which has dedicated fields for Contact and Account (both lookups). This method of uploading new documents and updating new field values to a custom record is often used when dealing with integrations and digital experience users. You can easily build a similar automation if a ContentDocumentLink for the Account needs to be created when the file is uploaded to a standard object like Contact.

Follow these steps to build your flow:

1. Trigger your record-triggered flow when a ContentDocument record is created (no criteria)
2. Add a scheduled path to your flow and set it up to execute with 0 min delay. Under advanced settings, set up the batch size as 1. Async seems to work, as well. I will explain the reason for this at the end of the post.
3. Get all ContentDocumentLink records for the ContentDocument
4. Check null for the get in the previous step (may not be necessary, but for good measure)
5. If not null, use a collection filter to filter for all records where the LinkedEntity Id starts with the prefix of your custom object record (I pasted the 3 character prefix into a constant and referenced it). Here is the formula I used: LEFT({!currentItem_Filter_Staging.LinkedEntityId},3)= {!ObjectPrefixConstant}
6. Loop through the filtered records. There should be only one max. You have to loop, because the collection filter element creates a collection as an output even for one record.
7. Inside the loop, get the staging record. I know, it is a get inside the loop, but this will execute once. You can add a counter and a decision to execute it only in the first iteration if you want.
8. Build two ContentDocumentLink records using an assignment. One between the ContentDocument and the Contact on the staging record, the other one between the ContentDocument and the Account. You could add additional records here for sharing.
9. Add your ContentDocumentLink records to a collection.
10. Exit the loop and create the ContentDocumentLink records using the collection you built in one shot.

Here is a screenshot of the resulting flow.

Here is what happens when you create a staging record and upload a file to Salesforce using the related list under this record.

Here is the resulting view on the Contact and Account records.

Why is the Scheduled Path or Async Path Necessary?

When a file is uploaded, a ContentDocument record and a ContenDocumentVersion record are created. The junction object for the ContentDocumentLink record will need to be created after these records are created, because the relationship is established by populating these Ids on this record. When you build the automation on the immediate path, your get will not find the ContentDocumentLink record. To ensure Salesforce flow can find the record, use either async path or scheduled path.

When you build the automation on the immediate path, the ContentDocumentLink records are not created. You don’t receive a fault email, either, although the automation runs well in debug mode. I wanted to observe this behavior in detail, and therefore I set up a user trace to log the steps involved. This is the message I have found that is stopping the flow from executing:
(248995872)|FLOW_BULK_ELEMENT_NOT_SUPPORTED|FlowRecordLookup|Get_Contact_Document_Links|ContentDocumentLink
According to this the get step for ContentDocumentLink records cannot be bulkified, and therefore the flow cannot execute. Flow engine attempts to always bulkify gets. There is nothing fancy about the get criteria here. What must give us trouble is the unique nature of the ContentDocumentLink object.

The async path seems to bypass this issue. However, if you want to ensure this element is never executed in bulk, the better approach is to use a scheduled path with zero delay and set the batch size to one record in advanced settings. I have communicated this message to the product team.

Please note that the scheduled path takes a minute to execute in my preview org. Be patient and check back if you don’t initially see the new ContentDocumentLink records.

Conclusion

In the past, handling file uploads gave flow builders a lot of trouble, because the related objects did not support flow triggers.

Now that we have this functionality rolling out in the latest release, the opportunities are pretty much limitless. The functionality still has its quirks as you can see above.

I would recommend that you set up a custom metadata kill switch for this automation so that it can easily be turned off for bulk upload scenarios.

Watch the video on our YouTube channel.

[youtube https://www.youtube.com/watch?v=Gl0XCtMAhmc?feature=oembed&w=800&h=450]

Explore related content:

Top Spring 26 Salesforce Flow Features

Should You Use Fault Paths in Salesforce Flows?

How to Use Custom Metadata Types in Flow

See the Spring 26 Release Notes HERE.

Top Spring ’26 Salesforce Flow Features

What are the new features about? Spring 26 brings new screen, usability and platform enhancement features. Let’s dive into the details.

Top Screen Flow Spring 26 Features

It seems like most of the new features involve screen flows.

I will not go into further detail, but this release introduces yet another file upload component for screen flows: LWR File Upload Component for Experience Cloud.

Here are the rest of the screen flow improvements.

Screen Flow Screen Element and Component Style Enhancements

Screen flow screen element gets features that allow you do set the background, text and border colors. Border weight and radius can be adjusted. For input components, in-focus color for text can be differentiated. Flow buttons also get similar adjustments gaining the ability to change colors on hover over.

Any styling changes you set override your org or Experience Cloud site’s default theme.

Remember to keep your color and contrast choices in check for accessibility. Don’t do it as I did below. Go to the WebAIM contrast checker website and plug in your color codes to check whether their contrast is sufficient for accessibility.

Screen Flow Message Element

Screen Flow Message Element leverages the new styling options to display a message on the screen. It has a pulldown that allows you to create an information, success, warning or an error message. These come with standard color sets, which will direct flow developers in using a standard visual language.

This functionality is compliant with A11y for accessibility.

See all the four types on the same screen below.

Screen Flow Kanban Component (Beta)

The new Kanban component allows you to organize records into cards and columns. This is particularly useful for visualizing process phases and managing transitions across your workflow.

Use the new Kanban Board component to show records as cards in columns that represent workflow stages, without custom Lightning implementations. The Kanban Board is read-only, so users can’t drag cards between stages at run time.

Data Table Column Sort and Row Value Edit (TBD)

Now the user can sort the data table by columns and edit text fields in rows. This feature is not available in the preview orgs. The product team is working hard in the background to make this into the Spring 26 release. This functionality is slated to make it to the release at the last minute.

Preview Files Natively in Screen Flows

Elevate document-based processes by enabling your users to review file content directly within a screen flow. The new File Preview screen component removes the requirement to download files externally, ensuring easier document review and approval workflows.

This component seems to be already in production.

Open Screen Flows in Lightning Experience with a URL

Previously, when you opened a flow via URL, it did not launch in lightning experience. Now, it will launch in lightning preserving the experience your user is used to especially when they are working on a customized lightning console app.

I will quote the release notes for this one.

“To open a flow in Lightning Experience, append /lightning/flow/YourFlowNameHere to your URL. To run a specific flow version, append /lightning/flow/YourFlowNameHere/versionId to your URL. Flows that open in Lightning Experience have improved performance because most required Lightning components are already loaded into the browser session. In Lightning console apps, your tabs are preserved when a flow opens, and you can switch to other tabs while the flow is working. Using the new URL format also ensures that your browser behaves consistently, with forward, back, and your browser history working as expected.

To pass data into a flow through its URL, append ?flow__variableIdHere=value to the end of your URL. For example, to pass a case number into a flow, /lightning/flow/YourFlowNameHere?flow__variableIdHereID={!Case.CaseNumber}.

Use & to append multiple variables into a flow. For example, /lightning/flow/YourFlowNameHere?flow__varUserFirst={!$User.FirstName}&flow__varUserLast={!$User.LastName} passes both the user first name and last name into the flow.”

Usability and Platform Features

I listed all of the screen flow features above. The following two items are huge usability improvements that also involves screen management for the flow canvas, not just only for screen flows.

Collapse and Expand Decision and Loop Elements

When your flow gets to big and you need to Marie Kondo (tidy up) your flow canvas, you can collapse the decision and loop elements that take up a lot of real estate. You can always expand them back when needed.

Now you can collapse and expand branching elements with Flow Builder, including Wait, Decision, Loop, Path Experiment, and Async Actions, helping you focus on the key parts of your flow.

This layout is saved automatically and locally in your browser, making it easier to return to your work without changing the view for other users.

Mouse, Trackpad and Keyboard Scroll

Now you don’t have to drag or use the scroll bar to move the flow around on the flow canvas. You can use vertical and horizontal wheels on your mouse, the arrows keys on your keyboard or your trackpad if you have one.

No need to use Salesforce Inspector Reloaded to get this functionality any more. Thanks to Salesforce Inspector Relaoded for filling the gap in the mean time.

Content Document and Content Version Flow Triggers for Files and Attachments (Beta)

Salesforce delivered a new event type in the last release that could trigger flows for standard object files and attachments. The functionality was limited. In this release, Salesforce gave us the ability to trigger on all new files/attachments and their updates for all objects.

I was told by the product team that this functionality will be released as beta.

Flow Logging

I am not exactly sure what has been improved here. Salesforce had previously announced additional flow logging capabilities leveraging Data Cloud. Now, a new flow logging tab has been added to the Automation Lightning App.

Debug Improvements

The debug in the flow builder will now remember the record that it ran on and the updated field value if it is running in an update scenario. Debug inputs such as triggering record values, debug options, and input variable values now remain set when you save flow changes within your Flow Builder session. The user will need to click a reset button to disassociate the debug run from the input for the last run. This change is intended to make debug reruns faster.

Flow builder will preserve debug configurations when you save changes to your flow. Refreshing your browser or closing Flow Builder clears all debug settings.

Conclusion

Salesforce product teams work hard delivering new features for every release. Spring 26 release brings significant new improvements for the flow builder. I would have liked to see additional capabilities coming for flow types other than screen flows. This release seems to be a lighter release in that area.

Additional bonus features include request for approval component for lightning page layouts (highly-requested feature), compare screen flow versions, and associating flow tests with flow versions.

The release notes are still in preview. And we could still have new functionalities removed or added in the release cycle.

This post will be updated as additional details are made available.

[youtube https://www.youtube.com/watch?v=eZC_8W1IbUs?feature=oembed&w=800&h=450]

Explore related content:

Salesforce Optimizer Is Retired: Meet Org Check

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

Automate Permissions in Salesforce with User Access Policies

Spring ’26 Release Notes: Highlights for Admins and Developers

​​​​What Is Vibe Coding? And What’s New in Agentforce Vibes for Developers?

Should You Use Fault Paths in Salesforce Flows?

If you build enough Flows, you’ll eventually see the dreaded flow fault email. Maybe a record you tried to update was locked, a required field value was not set in a create operation, or a validation rule tripped your commit. Regardless of the root cause, the impact on your users is the same: confusion, broken trust, and a support ticket. The good news is you can catch your faults using the fault path functionality. In this post, we’ll walk through practical patterns for fault handling, show how and when to use custom error element, and explain why a dedicated error screen in screen flows is worth the extra minute to build. We’ll also touch on the roll back records element for screen flows where this functionality can make a difference.

Why Fault Paths Matter

Faults are opportunities for your Salesforce Org automation to improve. While unhandled faults are almost always trouble, handled faults do not have to be a huge pain in our necks.

The Core Building Blocks of Flow Fault Handling

1) Fault paths
Gets (SOQLs), DMLs (create, update, and deletes) and actions support fault paths. Fault paths provide a way for the developer to determine what to do in the event of an error.
2) Fault actions
You can add elements to your fault path to determine the next steps. You can also add a custom error element in record-triggered flows or error screens in screen flows for user interactivity. Multiple fault paths in the flow can be connected to the same element executing the same logic. A subflow can be used to standardize and maintain the fault actions such as temporarily logging the fault events.

Logging Errors

Here is a list of data that may be important to include in your fault communications and logging:

• Flow label
• User Name
• Date/Time
• Technical details (e.g. $Flow.FaultMessage)
• Record Id(s) and business context (e.g., Opportunity Id, Stage)
• User-friendly message (plain English)

Subflow Solution

The advantage of a subflow when dealing with fault paths is that you can modify the logic once on a central location. If you want to start logging temporarily, you can do that without modifying tons of flows. If you want to stop logging, this change can be completed fairly easily, as well.

Inside the subflow, decide whether to:

• Log to a custom object (e.g., Flow_Error__c)
• Notify admins via Email/Slack

Meet the Custom Error Element

The Custom Error element in Salesforce Flow is a powerful yet often underutilized tool that allows administrators and developers to implement robust error handling and create more user-friendly experiences. Unlike system-generated errors that can be cryptic or technical, the Custom Error element gives you complete control over when to halt flow execution and what message to display to your users.

The Custom Error element lets you intentionally raise a validation-style error from inside your flow, without causing a system fault, so you can keep users on the same screen, highlight what needs fixing, and block navigation until it’s resolved. Think of it as flow-native inline validation.

What The Custom Error Element Does

It displays a message at a specific location (the entire screen or a specific field) and stops the user from moving forward. This functionality does present a less than ideal self-disappearing red banner message if you make a change to a picklist using the path component, though. Refrain from using the custom error messages in these situations.

The unique thing about the custom error message is that it can be used to throw an intentional exception to stop the user from proceeding. In these use cases, it works very similarly to a validation rule on the object.

This becomes particularly valuable in complex business processes where you need to validate data against specific business rules that can’t be easily captured in standard validation rules. For instance, you might use a Custom Error to prevent a case from being closed if certain required child records haven’t been created, or to stop an approval process if budget thresholds are exceeded.

Please note that custom error messages block the transaction from executing, while a fault path connected to any other element will allow the original DML (the triggering DML) to complete when the record-triggered automation is failing.

Custom Error Screen in Screen Flows

Incorporating a dedicated custom error screen in your screen flows dramatically improves the user experience by transforming potentially frustrating dead-ends into helpful, actionable moments. When users encounter an error in a screen flow without a custom error screen, they’re often left with generic system messages that don’t explain what went wrong in business terms or what they should do next, leading to confusion, repeated help desk tickets, and abandoned processes.

A well-designed custom error screen, however, allows you to explain the specific issue in plain language that resonates with your users’ understanding of the business process. Beyond clear messaging, custom error screens give you the opportunity to provide contextual guidance, such as directing users to the right person or department for exceptions, offering alternative paths forward, or explaining the underlying business rule that triggered the error. You can also leverage display text components with dynamic merge fields to show users what caused the problem turning the error into a learning moment rather than a roadblock. Additionally, custom error screens maintain your organization’s branding and tone of voice, include helpful links to documentation or knowledge articles, and pair with logging actions to give you valuable insights into potential process improvements or additional training needs.

Here is an example custom error screen element format (customize to your liking):

Error
Your transaction has not been completed successfully. Everything has been rolled back. Please try again or contact your admin with the detailed information below.
Account Id: {!recordId}
Time and Date: {!$Flow.CurrentDateTime}
User: {!$User.Username}
System fault message:
{!$Flow.FaultMessage}
Flow Label: Account - XPR - Opportunity Task Error Screen Flow

The “Roll Back Records” Element

There are use cases in screen flows where you create a record and then update this record based on follow-up screen actions. You could be creating related records for a newly created record, which would require you to create the parent record to get the record Id first. If you experience a fault in your screen flow, record(s) can remain in your system that are not usable. In these situations the Roll Back Records element lets you undo database changes made earlier in the same transaction. Roll Back Records does not roll back all changes to its original state, it only rolls back the last transaction in a series of transactions.

Tips for fewer faults in the first place

Here are some practical tips:

• Validate early on screens with input rules (Required, min/max, regex).
• Use Decisions to catch known conflicts before DML.
• Place DMLs strategically in screen flows: Near the end so success is all-or-nothing (plus Roll Back Records if needed) or after each screen to record the progress without loss.

The fewer faults you surface, the more your users will trust your flows.

Putting it all together

Here’s a checklist you can apply to your next Screen Flow:

• Every DML/Callout element has a Fault connector.
• A reusable Fault Handler subflow logs & standardizes messages.
• Custom Error is used for predictable, user-fixable issues on screens.
• A custom error screen presents clear actions and preserves inputs.
• Technical details are available, not imposed (display only if helpful).
• Roll Back Records is used when it matters.
• Prevention first: validate and decide before you write.

Other Considerations

When you use a fault path on a record-triggered flow create element, and your create fails, please keep in mind that you will get a partial commit. This means the records that fail won’t be created while others may be created.

Example: You are creating three tasks in a case record-triggered flow. If one of your record field assignments writes a string longer than the text field’s max length (for example, Subject) and you use a fault path on that create element, one task fails while the other two create successfully.

Conclusion

My philosophy regarding fault paths is to add them to your flows, but never go down them if possible. When you see you are going down fault paths, then that means you have opportunity for improvement in your automation design.

Every fault you handle offers insight into how your flow behaves in the real world. Each one reveals something about the assumptions built into your automation, the data quality in your org, or the user experience you’ve designed. Treating faults as signals rather than setbacks helps you evolve your automations into resilient, reliable tools your users can trust. Over time, these lessons refine both your technical build patterns and your understanding of how people interact with automation inside Salesforce.

Explore related content:

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

Should You Leave Unused Input and Output Flow Variables?

How To Build Inline Editing for Screen Flow Data Tables in Salesforce

Salesforce Flow Best Practices

Add Salesforce Files and Attachments to Multiple Related Lists On Content Document Trigger

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

Should You Leave Unused Input and Output Flow Variables?

In Salesforce Flow, input variables are special placeholders that allow data to be passed into a flow from an external source, such as a Lightning page, a button, another flow, or even an Apex class, so that the flow can use that data during its execution. When you create an input variable in Flow Builder, you mark it as Available for Input, which makes it visible and ready to receive values from outside the flow. Output variables, on the other hand, are used to send data out of a flow so it can be consumed by whatever triggered or called the flow, such as another flow, a Lightning web component, or an Apex class. When you create a variable and mark it as Available for Output, the flow can pass its final or intermediate values back to the caller once it finishes running.

Input variables are especially useful for building modular, reusable flows. You can design them to handle different scenarios based on the values provided at runtime. For example, a record ID provided as an input variable can help the flow retrieve and update that specific record without needing user input. By leveraging input variables, you can keep flows flexible, reduce duplication, and make them easier to maintain.

Similarly, output variables are powerful when building modular, subflow-based solutions. The parent flow can feed inputs to the subflow, receive outputs in return, and then continue processing without extra queries or logic. For example, a subflow might calculate a discount amount or generate a new record ID. It can then return it as an output variable for the parent flow to use. Output variables make flows more reusable, keep processes streamlined, and allow different automation components to share data seamlessly.

Security Implications of Variables Available for Input and Output

In programming, a variable’s scope defines the region of code where it exists and can be used, such as within a specific method, a class, or an entire module. For example, a variable defined inside a method is local to that method and cannot be seen or changed by code outside it, much like keeping notes in your own locked desk drawer. This “privacy” ensures that internal details remain protected from unintended interference, which is a key aspect of encapsulation in programming. If you want other parts of the program to access the data, you must explicitly expose it through return values, public properties, parameters, or other controlled interfaces. This principle not only prevents accidental bugs but also supports security. Sensitive data and logic remain inaccessible unless intentionally shared, helping keep the system stable, predictable, and easier to maintain.

When you allow input variables for your flow, you allow external environments that run this flow to pass parameters into it. This potentially makes your flow vulnerable to outside attacks. When you configure output variables for your flow, you are creating a risk of external environments accessing flow output data. This is often data recorded in your Salesforce org. This data may include personally identifiable information or sensitive data.

In addition, avoid using inputs that are easy to guess. If you look up a contact record based on their email address, attackers may guess the email address after a few tries (firstname.lastname@gmail.com for example).

What About Flows Built for Digital Experience Guest Users?

When you build a flow and deploy it on a digital experience site, where the guest user can execute it without logging in, you are exposing your flow to the outside world. This scenario makes your flow even more vulnerable to outside attacks.

Guest User Means Anybody Can Access Any Time

First of all, please know that this is a very risky approach. You should assume anybody can run that flow anytime, which is what you allowed. Make sure that only limited inputs and outputs are defined and used. The flow should only execute a limited scope that it absolutely needs. You should not allow the flow to perform a multitude of operations because you aim for flexibility. Test many scenarios to ensure attacks can not derail your flow and trick it to perform operations that it is not intended to perform.

Limit the Data

Furthermore, you should not allow the flow to access any information it does not need to see. If you are dealing with records or record collections, make sure your gets specify fields that are absolutely necessary. Do not get the drivers license number for the contact when you just need the name. In this scenario, do not let Salesforce automatically decide what fields to get. Also, when performing updates, do not update all the field values on the record. Just update whichever field is important to update for your process.

Isolate the Elevated Functionality

Finally, you may be tempted to set your flow to run in system context without sharing, or to allow a guest user to view records in the org through sharing rules. Both scenarios introduce additional risks that must be carefully considered.

When allowing your automation to run in system context without sharing, isolate the necessary part into a subflow. Ensure that logic is tightened well from a security standpoint. Do not run the whole flow in system context without sharing mode. Just run the necessary part in a subflow using this elevated setting.

Screen Flows and Reactivity

Whether you allow elevated access or not, screen flows present a couple of inherited risks.

When you pass information to a data table, lightning web component or a screen action, that information is accessed by your browser locally. If you feed a collection of contact records to a datatable and get all field values before you go to the data table screen, the local browser will see all the field values on the record. This happens before the user interacts with the table. The user can see these values.

Recent developments of reactivity for screen flows are fantastic from a UI standpoint, but further complicate the security risks. The more reactive functionality you use in your flow, the more data you handle locally in your browser.

Conclusion

When flow builders, especially new starters, build flow variables, they often freely check available for input and available for output checkboxes. They do this thinking the alternative would limit them. This is risky and not necessary. You can change these settings at any time without having to create or recreate variables.

Always plan your inputs and outputs carefully and review them at the end of development. Make sure you don’t have any unused variables still accepting inputs or producing outputs.

In this era, where we hear the Salesforce name associated with client data security breach incidents, apply extreme security caution when dealing with automation.

This post is part of our Flow Best Practice series. See the other posts HERE.

Sources and references:

Building Secure Screen Flows For External User Access by Adam White

Data Safety When Running Screen and Autolaunched Flows in System Context – Salesforce Help

Explore related content:

How To Attach Files Using the Flow Email Action in Salesforce

Getting Started with Salesforce Data Cloud: Your Roadmap to Unified Customer Insights

How To Build Flex and Field Generation Prompt Templates in the Prompt Builder

#Apex #BestPractices #InputVariables #LowCode #OutputVariables #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #ScreenFlow #Security

Why Is Everyone Talking About Salesforce Flow Approvals?

In the Spring ’25 release, Salesforce introduced Flow Approvals to replace the legacy approval processes. This approval platform was based on the orchestration functionality. I recorded and released two videos and posts to share this functionality on Salesforce Break. The videos saw great interest from the community, they are about to reach 20K views soon. So, why is everyone talking about flow approvals?

There are multiple reasons:

1. Flow approvals are orchestration-based, but they are entirely free unlike other orchestrations.
2. Legacy approvals are really old. Salesforce has not been investing in them. They are past due for a remake.
3. Legacy approvals are limited. To enhance the functionality, clients had to use AppExchange solutions or paid alternatives by Salesforce like advanced approvals for CPQ.
4. Flow approvals allow for parallel approvals, dynamic steps, and flexibility in the approval process.

This is why I decided to create more content in this area, starting with:

1. A live course that teaches Flow Approval processes in depth, with hands-on practice. See the details here, and reach out if you’re interested.
2. Additional resources focused on solutions that bridge the gaps between Flow Approvals and Legacy Approvals, addressing the limitations of the new platform.

Here is the first post detailing a solution filling one of the gaps.

Flow Approvals Don’t Provide Sufficient Detail In The Related Lists

Here is the first point I would like to address: Flow approvals don’t provide good detailed information in the related lists of the object record like the legacy approvals did.

Solution: Build a screen flow with reactive data tables to show the approval submission records and their related records. Add the screen flow to a tab on the record page.

Salesforce provided a component that can be added to the record page. It is called the Approval Trace component. This provides some information about the approval process, but is not customizable. I asked myself how I can go beyond that, and decided to build a reactive screen flow with data tables to fill this functionality gap. Here is what the output looks like:

To build and deploy this flow, you need to follow these steps:

1. Build the screen flow.
2. Build the autolaunched flow that will fetch the data you will need. This flow will be used as the screen action in step one.
3. After testing and activation, add the screen flow to the record page.

If you have never built a screen flow with screen actions before, let me be the first one to tell you that step one and two are not really completed in sequence. You go back and forth building these two flows.

Let’s get started.

Build the Flow Approval Submission Screen Flow

What I usually do, when building these flows is that I first get the screen flow started. Then I build the autolaunched flow, and go back to the screen flow to build out the rest of the functionality. The reason is that the screen flow data tables will need the outputs from the autolaunched flow to be fully configured.

This is what the screen flow looks like, once it is completed.

For now, you can just ignore the loop section. This is there to ensure that there is a default selection for the first data table, when the flow first runs.

This is the structure of the flow excluding that part:

1. Get all approval submission records for the recordId that will be provided as input into the flow.
2. Check if there are approval submissions found.
3. Display a screen saying “no records were found,” if the get returns null.
4. Display a reactive screen mainly consisting of three data tables with conditional visibility calling an autolaunched flow as a screen action.

Here is what this screen looks like:

After you build, test, and activate the autolaunched flow, configure the screen action under the screen properties as shown below.

How the Loop Section Works

The first data table has an input parameter that determines the default selection, when the flow first runs. This is a record variable representing one of the members of the collection record variable that supplies the data. You need to loop the collection of records to get to the record variable. Follow these steps:

1. Loop the collection record variable which is the output of your get step. Sort the data by last modified date in your get step.
2. Assign the first member to a record variable.
3. Exit the loop without condition. Connect the path to the next element outside the loop.
4. Add the resulting record variable to the default selection parameter under the configure rows section of your data table.

This loop always runs once, setting the default selection to the most recent approval submission. This populates the related data tables when the flow first runs.

Build the Screen Action Autolaunched Flow for Related Lists

The autolaunched flow receives a single approval submission recordId as input. Then it gets the related records and data the screen flow needs, and returns the data as output.

Here is a screenshot of the autolaunched flow.

This flow executes the following steps:

1. Gets the approval submission data.
2. Gets the user data for the submitter to resolve the full name.
3. Gets approval work items.
4. Checks null and sets a boolean (checkbox) variable when the get returns null. The output uses this variable to control conditional visibility of the relevant data table. If found this method yields the best results.
5. Get approval submission details.
6. Checks null and sets a boolean variable when the get returns null. This variable is then used in the output to drive conditional visibility of the relevant data table.
7. Assigns the get results to output collection record variables.

Final Deployment Steps

After testing and activating the autolaunched flow, you need to add the flow to the screen flow as the screen action. The flow input will be fed from the selection of the first data table. You will see that this step will make all the outputs of the autolaunched flow available for the screen flow. Using these outputs build the additional two data tables and configure the conditional visibility.

After testing and activating your screen flow, add the flow to the record page on a dedicated new tab (or to a section on an existing tab). Select the checkbox to pass the recordId to the flow. Note that this flow will work with any record for any object.

Limitations and Suggested Improvements

While this screen flow provides a lot of detail and customization options it has two limitations:

1. By default, the data table does not resolve and display record names in lookup fields when you add these fields as columns. To address this, I added the submitter’s full name in a read-only text field for display on the screen. Workaround: Create formula fields on the object and display those in the data table.
2. The data tables do not provide a clickable link. Combined with the limitation above, you can create a formula field on the object to address both of these gaps: show the record name and make it a clickable link. Here is the formula example you need for this (shout out goes to Brad Weller for his contribution): HYPERLINK("/" & Id, Name, '_self')

While I wanted to make these additions to these flows, I did not want to add custom fields to the objects. It should be your decision whether you want to do that or not.

Install the Package to Your Dev Org

Here is the second generation unprotected package for these two flows that you can install in your Dev Org:

Install the Unprotected 2GP

For a more visual walk through of how these flows are built, watch the Salesforce Break YouTube video below.

With Salesforce phasing out legacy approvals, mastering Flow Approvals is essential to keep your org’s processes modern, flexible, and future-ready. Gain the confidence to handle any approval challenge with solutions that work seamlessly in real-world Salesforce environments HERE.

Explore related content:

Supercharge Your Approvals with Salesforce Flow Approval Processes

When Your DMLs Have Criteria Conditions Other Than Id

Start Autolaunched Flow Approvals From A Button

Get Ready for the New Time Data Type – Summer ‘25 Flow Goodness

#AutolaunchedFlow #FlowApprovals #FlowBuilder #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

Simplify Salesforce Integrations with Declarative Webhooks

Salesforce continues to invest in tools that simplify integration tasks for administrators. Low-code set up for integrations are possible on the Salesforce platform today. However, the functionality still seems to be dispersed all over the platform utilizing several tools, and keeping the difficulty of setup relatively high. This is where Declarative Webhooks comes in. This platform makes inbound and outbound integrations easy, and keeps all your configurations together in one single app.

What is Declarative Webhooks?

Declarative Webhooks is a native Salesforce application developed by Omnitoria. It allows admins to build significant, scalable integrations with external platforms without writing code. Built to work with REST APIs that use JSON or x-www-form-urlencoded data, the app makes it possible to configure both outbound and inbound connections from within Salesforce. It’s ideal for admins, developers, and operations teams looking to connect Salesforce to third-party tools quickly and securely.

Declarative Webhooks currently holds a 5-star rating on the AppExchange, with positive feedback from users across industries.

Key Declarative Webhooks Features

Declarative Webhooks enables bidirectional integrations. You can send data out of Salesforce (outbound) by triggering callouts through Flow, Process Builder, Apex, custom buttons, or scheduled batches. You can also receive data from external systems (inbound) by defining endpoints within Salesforce that respond to external webhooks.

Unlike standard Salesforce tools, Declarative Webhooks actually creates and hosts inbound URLs—eliminating the need for middleware, and enabling real-time sync with external systems directly from your org.

The interface is entirely point-and-click, making setup approachable even for non-developers. The app includes template-based configurations that streamline implementation without the need for custom Apex. Help and guidance is provided throughout the UI each step of the way.

Security and flexibility are top priorities. Declarative Webhooks supports a variety of authentication methods, including OAuth and Basic Authentication, and allows you to configure secure handling of credentials and external tokens.

For more advanced use cases, the app includes features like retry logic, callout sequences, and detailed error handling. You can tailor integrations to your needs using scheduling tools or triggering logic from inside Salesforce.

Real-World Use Cases

Slack Webhook

Now granted, this can also be achieved with Salesforce-Slack actions, however, I wanted to take this opportunity to trigger Slack workflows with Webhooks, and demo the Declarative Webhooks functionality with a simple use case.

I set up a Slack workflow that triggers based on a webhook. This workflow posts a message to a channel and adds the name of the person that is passed into the workflow via the webhook to a list of contacts.

You can see the configuration of the Slack workflow and the Slack output results below.

How Did I Configure Declarative Webhooks to Achieve This Result?

First you need to install Declarative Webhooks from Salesforce AppExchange. I will give you the link further down on this post. This app is free to install and try.

• Complete the Slack configuration of the workflow. Slack will give you a webhook URL.
• Configure Declarative Webhooks and add the URL to the configuration page. Make sure you add the domain URL to Salesforce Remote Site Settings.

• Test and activate your callout
• Use one of the many methods available in Declarative Webhooks to trigger the callout from Salesforce.

Inbound Call Template for Zoho Campaigns

How Did I Configure Declarative Webhooks and Zoho Campaigns to Achieve This Outcome?

• Set up an Inbound Call Template on Declarative Webhooks. The magic on this platform is that it generates an external endpoint URL for you. You can chose to authenticate or not.

• Create a webhook on the Zoho Campaign side and pass the Name and Email of the contact to Salesforce. Enter the URL generated by Declarative Webhooks here.

• Build an autolaunched flow to update the checkbox on the matching record.

• Test and activate your flow and Declarative Webhooks template.
• Unsubscribe the contact from the list on the Zoho Campaigns side and see the magic unfold.

I really liked this functionality. The logs show whether the flow executed successfully. For future enhancements, I would like for the Declarative Webhooks logs to also show output variable values coming from the flow.

Pricing Overview

Declarative Webhooks is free to install and use in Salesforce sandbox environments indefinitely. In a production or developer org, users get a 30-day free trial. After that, the app remains free for basic use, up to 100 inbound and 100 outbound calls per month, using one outbound and one inbound template.

For organizations that need more capacity or advanced functionality, paid plans are available. These plans scale with usage and support additional templates, retries, and enhanced features. Nonprofit discounts are available, making the app accessible to mission-driven organizations.

Follow this link to find out more about the product and try it yourself.

Why Declarative Webhooks?

This app removes the need for manual data entry and reduces the likelihood of human error. It lets teams centralize their business operations within Salesforce, replacing disconnected workflows with streamlined automations. Whether you’re connecting to popular SaaS tools or custom-built systems, Declarative Webhooks empowers teams of all skill levels to build reliable integrations that scale with their business.

How to Get Started

You can install Declarative Webhooks directly from the AppExchange. The installation process is quick, and the setup guide walks you through each step. Start experimenting in a sandbox or production trial, and configure your first outbound or inbound connection using the built-in templates. Whether you’re an admin looking to eliminate duplicate entries or a developer needing a fast integration framework, this tool provides the support you need to get started quickly. 

Final Thoughts

I liked how Declarative Webhooks brought various integration methods together in one app. I especially like the inbound call functionality. Ease of setup, flexible pricing, and native integration with Salesforce automation tools are attractive features for Salesforce Admins. If you are in the market for integration solutions, I recommend you check out Declarative Webhooks by Omnitoria here.

This post was sponsored by Omnitoria.

Explore related content:

Getting Started with Salesforce Data Cloud: Your Roadmap to Unified Customer Insights

How To Use Custom Permissions In Salesforce Flow

Create Document Zip Archives in Salesforce Flow

Dynamically Create Documents Using PDF Butler

#DeclarativeWebhooks #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

When Your DMLs Have Criteria Conditions Other Than Id

The Update Records element in Salesforce Flow is a powerful tool that allows you to modify existing records without writing any code. It’s commonly used to change field values and update statuses. You can configure it to update a specific record (like a record from the trigger or a record you’ve retrieved in a prior element), or you can set conditions to update multiple records that meet certain criteria. Best practice is to keep your updates efficient. Limit the number of records updated when possible, and always ensure that your flow logic avoids unnecessary updates to prevent hitting governor limits or creating infinite loops. Use it thoughtfully to streamline processes and maintain clean, accurate data.

Update Records

When you update records, there are three ways you can configure the update element:

1. Update using Id(s): Your update element can point to one record Id or multiple record Ids using the IN operator when executing the update. This is an efficient alternative, as the record(s) are uniquely identified. This alternative consumes one DML against your governor limit.
2. Update using a collection: This method is efficient, because the update element always consumes one DML against your governor limit, regardless of how many records your are updating in one show. You can update up to 10K records in one update element.
3. Update using criteria conditions for field values other than Id: When updating multiple records, we can also set conditions and update all the records that meet the conditions. In this case, Salesforce queries the database and gets the records that will be updated, and performs the update. This method therefore consumes one SOQL and one DML against your governor limit. It is possible that one or no record meets the conditions, as well.

Update Using Criteria Conditions For Field Values Other Than Id

Let’s expand on the last method. For an inactive account, you may want to update all open cases to closed status. In a flow we could configure the update element with the following conditions:

• AccountId = Inactive Account
• Closed = false (case status is not closed)

And for these accounts the field update that will be performed is as follows:

Status = Closed (set status to closed)

In this scenario, what Salesforce will do is query and find the records using the two conditions listed above (SOQL) and set the Status field on these records to Closed (DML).

Now, is this a bad thing? Not necessarily. This is a little known fact, that you should keep in mind when optimizing your flow for governor limit usage.

What is the alternative? I guess you could perform an update using one of the other alternatives listed above. Let’s look at these alternatives in detail:

Update Using Id(s)

If you wanted to use this method you could get the records according to the criteria conditions, and extract the Ids and put them into a text collection using the transform element, and do the update using the IN element. This alternative is more complicated. It does not bring any efficiencies.

Update Using a Collection

You could get a collection of records using the conditions, loop through each item to update the case status, or possibly use the transform element to update the status in one shot – depending on your use case – then go to update using the processed collection. Too complicated. This alternative still uses one SOQL and one DML.

Conclusion

Updates that include conditions beyond specifying the Id of the record consume one SOQL and one DML against your execution governor limits; make sure you check and control your governor limit usage.

Explore related content:

Salesforce Flow Best Practices

Flow Naming Convention Tips

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

How Many Flows Per Object?

#Automation #DML #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #UpdateElement

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

The Salesforce Flow Data Table component is a powerful screen element that allows users to view and interact with records in a structured, spreadsheet-like format within a Flow. It supports features like record selection, sorting, and filtering, making it ideal for building guided user experiences. For example, in a product selection use case, a sales rep can launch a Flow that displays a list of products retrieved from the Product2 or PriceBookEntry objects. Using the data table, the rep can easily compare options and select multiple products to add to an opportunity, all within a single, streamlined Flow screen.

The data table component has been added to Salesforce based on the success of Eric Smith’s open source data table component published on UnofficialSF. The out of the box component is still not as powerful as the unofficialSF sibling.

In this post, I will show you how I leveraged the transform element inner join functionality to bring together Product2 or PriceBookEntry field values which I showed in the unofficial SF data table component.

The inner join functionality is a powerful one. It falls short of its full potential, because flow builder does not offer a way for us to generate custom data types to hold the information we bring together.

I created a placeholder Apex-defined data type which I used on the output side of the transform element. The unofficial SF data table supports the display of Apex-defined collection data. Leveraging this functionality, I brought the field values of both Product and Price Book Entry objects for the user to make an informed product selection.

User will select products and add them to the opportunity record. When making the selection, user should be able to see product information and price book entry information from the selected price book on the same row: Product name, code, family, description and unit price.

Apex-Defined Data Types in Flow

Apex-Defined Data Types allow developers to create custom, structured objects in Apex that can be used as inputs and outputs within Flow. These types enable more complex data handling than standard Flow variables, supporting multiple fields, including nested data, within a single variable. For example, you might define an Apex class that bundles together a product’s name, price, discount, and inventory status, then use it in a Flow to display custom pricing logic or pass structured data between Flow and Apex actions. This approach enhances flexibility and scalability when building advanced automation.

The key to defining an Apex-defined data type available for flow is the @AuraEnabled annotation in the Apex class. Once you write an Apex class that defines the fields in the Apex-defined object and deploy it to production, you don’t need to do anything in the flow builder to make this data type available in flow. In the areas where and Apex-defined resource selection is allowed, the new data type will be accessible.

I decided to create an Apex-defined data type with various multiple fields that I can use in the flow builder. The fields I generated are:

• 4 strings
• 2 numbers
• 2 currency fields
• 1 boolean (checkbox)

Here is the simple (the name says complex, but it is simple) Apex code that does the trick:

/** * ComplexDataCollection - Apex-defined data type for Salesforce Flow */public class ComplexDataCollection {        @AuraEnabled    public String string1 { get; set; }    @AuraEnabled    public String string2 { get; set; }    @AuraEnabled    public String string3 { get; set; }    @AuraEnabled    public String string4 { get; set; }    @AuraEnabled     public Decimal number1 { get; set; }       @AuraEnabled    public Decimal number2 { get; set; }       @AuraEnabled    public Decimal currency1 { get; set; }        @AuraEnabled    public Decimal currency2 { get; set; }     @AuraEnabled    public Boolean boolean1 { get; set; }  }

You will need a test class to deploy this code to production. That should be easy especially with the help of AI, but let me know if you need me post the test class.

Transform and Join Product and Price Book Entry Field Values to Populate the Apex-Defined Data Type

Follow these steps to prepare your data for the data table component:

1. Get all the Price Book Entries for one Price Book.
2. Get all the Products in the Org (limit your get at 2,000 records for good measure).
3. Join the two collections in the transform element using the Product2 Id.
4. Map the fields from source collections to the Apex-defined data type.

Here is more detail about the transform element configuration:

1. Add the transform element.
2. Add the price book entries collection from the get element on the left side.
3. Add the product collection on the left side.
4. Add an Apex-defined collection on the right side. In my case this is called “ComplexDataCollection“. Search by name. Make sure you check the collection checkbox.
5. Click on the first collection on the left side at the top collection level (not next to the individual fields). Connect this to the collection on the right side. You will see instructions for inner join.
6. Click on the second collection on the left side. You should see a join configuration screen. Configure your join. More instructions will follow.

Configure your join:

1. Left source and right source order does not matter for inner join. Select both collections on the left side.
2. The join key will be Product2 on the PriceBookEntry and Id on the Product2.
3. Select the fields you want on the output. For me these are: Name, ProductCode, UnitPrice, Family, Description. I added also isActive which I did not end up using in the data table.
4. Map these to your Apex-defined object fields: string1 through string4, currency1 and boolean1 (if you want isActive).

Your configured transform join should look like the screen image below.

Prepare the Apex-Defined Object Data for the Data Table

UnofficialSF data table supports Apex-Defined objects, but requires that the input is serialized. The data table cannot process Apex-Defined collection data as input. It expects a JSON format. More on that is available on Eric Smith’s post HERE.

To achieve this, you can either leverage Apex, or so the processing in flow. I tried both ways, and both methods works. Flow method requires looping.

Here is the Apex code for the invocable action that serializes the data:

/**  *  *  Sample Apex Class Template to get data from a Flow,  *  Process the data, and Send data back to the Flow *  This example translates an Apex-Defined Variable  *  between a Collection of Object Records and a Seraialized String *  Eric Smith - May 2020 * **/ public with sharing class TranslateApexDefinedRecords {         // *** Apex Class Name ***    // Attributes passed in from the Flow    public class Requests {            @InvocableVariable(label='Input Record String')        public String inputString;        @InvocableVariable(label='Input Record Collection')        public List inputCollection;     // *** Apex-Defined Class Descriptor Name ***    }    // Attributes passed back to the Flow    public class Results {        @InvocableVariable        public String outputString;        @InvocableVariable        public List outputCollection;    // *** Apex-Defined Class Descriptor Name ***    }    // Expose this Action to the Flow    @InvocableMethod    public static List translateADR(List requestList) {        // Instantiate the record collection        List tcdList = new List();    // *** Apex-Defined Class Descriptor Name ***        // Prepare the response to send back to the Flow        Results response = new Results();        List responseWrapper = new List();        // Bulkify proccessing of multiple requests        for (Requests req : requestList) {            // Get Input Value(s)            String inputString = req.inputString;            tcdList = req.inputCollection;// BEGIN APEX ACTION PROCESSING LOGIC            // Convert Serialized String to Record Collection            List collectionOutput = new List();   // *** Apex-Defined Class Descriptor Name ***            if (inputString != null && inputString.length() > 0) {                collectionOutput = (List)System.JSON.deserialize(inputString, List.class);    // *** Apex-Defined Class Descriptor Name ***            }            // Convert Record Collection to Serialized String            String stringOutput = JSON.serialize(tcdList);// END APEX ACTION PROCESSING LOGIC            // Set Output Values            response.outputString = stringOutput;            response.outputCollection = collectionOutput;            responseWrapper.add(response);        }        // Return values back to the Flow        return responseWrapper;    }}

Please note that this code refers to the name of the first Apex class. If you change the name, you will need to replace the references here, as well. Source: Eric Smith’s Blog.

See how the action will be used and configured in the image below.

Data Table Configuration

Here is how you configure the data table for this data:

1. Give your data table and API name
2. Scroll down to the advanced section and check the checkbox titled Input data is Apex-Defined.
3. Add the string variable you used to assign the value of the translate action output to Datatable Record String.
4. For the required unique Key Field input use the string that has the product code. For me this is string2.
5. To configure Column Fields add string1,string2,string3,string4,currency1 there.
6. Add 1:Name,2:Code,3:Description,4:Family,5:Price for Column Labels.
7. Configure Column Types by adding 1:text,2:text,3:text,4:text,5:currency there.

Once completed, you should see a similar output to this image below.

Conclusion

While this example illustrates the way Apex can boost the capabilities of flow, it is very cumbersome to set up this solution to leverage Apex-defined data types in the flow builder and in the data table.

This was more of an experiment than a solution I will use frequently.

If you don’t want to write code, you can easily create a custom placeholder object to achieve a similar result with the out of the box data table component.

I look forward to having this functionality built into the flow builder in the coming releases. I hope Salesforce product teams will prioritize this.

Explore related content:

How to Use the Data Table Component in Screen Flow

Send Salesforce Reports and Dashboards to Slack with Flow

How to Use the Repeater Component in Screen Flow

London’s Calling and Antipatterns to Look For in Flow

#DataTable #InnerJoin #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #TransformElement

Formula Resources in Criteria Conditions—Yes or No?

Salesforce Flow is a powerhouse for automation. And when it comes to building smart, dynamic Flows, Formula Resources play a critical role. They compute values for create, update and action elements, and calculate parameters to compare to in criteria conditions. But how exactly do they work? And where should you use them?

In this post, we’ll break down their use and explore whether we should be using them in criteria logic across various Flow elements.

What is a Formula Resource?

A Formula Resource in Flow is like a mini-calculator that evaluates to a single value (text, number, Boolean, or date) based on logic you define. Think of it like a formula field on an object, but used inside your Flow instead of the database.

Formula Resources use the same syntax as formula fields, including functions, operators, and references to variables or record fields.

Where Are Formula Resources Used?

You can use them in many flow elements, such as:

Decision Elements

• Evaluate complex conditions in a clean and reusable way.
• Reference a single Boolean formula instead of adding it to multiple outcomes.

Update Elements

• On the right side of a criteria condition that determines when to execute the update.
• On the right side of the field update to calculate and determine the new field value.

Get and Collection Filter Elements

You can use a formula resource on the right side of the criteria condition to specify which records you want in your output while configuring these elements.

Assignment, Create and Action Elements

While these elements don’t have criteria conditions in them, they can utilize formula resources to compute field and the parameter values.

Benefits of Using Formula Resources in Criteria

Using Formula Resources gives you an advantage when you want to use them again in your flow. Reusability would be the biggest advantage of using a formula resource in a criteria condition rather than building the logic in the element line by line.

One could also argue that formula resources can handle complex logic better in certain situations.

Formula Resource or Multi-line Criteria Conditions

Instead of inserting formula resources in criteria for decisions and updates, you should consider building multi-line conditions combined with AND and OR operators. Using formula resources may have negative performance impact on larger flows with many of them. They are computed several times throughout the execution of the flow, which may be more resource draining than building a multi-line criteria condition inside one element.

If you are not worried about performance in your particular case, or this is not a record-triggered flow, then this may not be a concern.

There are several other advantages of building criteria conditions directly inside an element like a decision:

• Readability: Even if you find a very descriptive name for your formula resource and add a description to it, it becomes a black box that you have to open, in order to understand the logic.
• Maintenance: Unless you use the same formula resource more than once in your flow, clicking through multiple formula resources to understand and update the logic can be more difficult than doing the same inside the element.
• Ease of debug: Your debug log can show more detail about how your criteria condition logic evaluates the data compared to the a formula resource that just returns a boolean value (true/false).

Pro Tip 1: When setting up formula resources, prefer returning a value to compare to, rather than a boolean value if your use case supports this. Example: Prefer returning the difference of days between today and the record created date, rather than setting up an IsRecent boolean formula resource that returns true when the record was created in the last seven days.

Pro Tip 2: If you need a not contains criteria condition and only see contains, you can go to custom logic in most cases and add a NOT() around the criteria condition with the contains clause.

Conclusion

Use formula resources only when you definitely need them. Consider setting up multi-line conditions combined with AND and OR operators instead. Name them clearly and add comments and descriptions.

If your use case requires setting up complex formula resources, break down the formula in smaller pieces and test them separately, before you put the whole thing together. Sometimes it may make sense to create a formula field on the object temporarily, when building a complex formula. This way, you can see the result of the computation immediately on multiple records (leverage list views).

Remember that the comment syntax used for Apex also works in formula resources. You can use it to add comments to complex formulas, like this: /* Example: This comment can wrap over multiple lines. */.

This post is part of our Best Series collection. Read the other posts HERE.

Explore related content:

How To Build Flex and Field Generation Prompt Templates in the Prompt Builder

Start Autolaunched Flow Approvals From A Button

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

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

A Comparative Look at Flow Decision Elements in Salesforce

Get Ready for the New Time Data Type – Summer ‘25 Flow Goodness

Salesforce Flow is constantly evolving, bringing us enhancements that make our lives as admins, developers, and business users much easier. The Summer ‘25 release is described as a big one, packed with substantial updates and quality-of-life improvements. Among these exciting additions is a feature many have been waiting for: native support for the Time data type in Flow.

What is the Time Data Type and Why is it Important?

The new Time data type is specifically designed for situations where the time of day matters, but the date does not. Previously, handling time-specific data in Flow without including the date could be complex. Summer ’25 changes that, allowing you to process data focused purely on time, down to the millisecond.

This capability is incredibly handy for a variety of use cases:

• Managing communication times, such as determining when to send an email.
• Checking if actions occur within specific business hours.
• Creating flows to send reminders based on a time before an event, like an email reminder 30 minutes before a meeting.

Where Can You Use the Time Data Type in Flow?

The Time data type is available across a wide range of Flow features, providing flexibility in how you build your automations. You can use Time fields and resources in:

• Various Flow elements, including Action, Assignment, Collection Filter, Collection Sort, Create Records, Delete Records, Decision, Get Records, Subflow, Transform, Update Records, and Wait for Conditions.
• Formula builder and expression builder.
• Resources such as variables and constants.
• As input and output for invocable actions.

When working with time values, you should use the hh:mm:ss.SSS AM/PM format, though including seconds or milliseconds is optional. For instance, 9:00 AM, 5:30:05 PM, and 14:45:53.650 PM are all valid time values.

New and Improved Time Functions

To complement the new data type, Salesforce Flow also introduces or enhances formula functions specifically for working with time. In the formula editor, you can now effectively use functions such as HOUR(), MINUTE(), SECOND(), MILLISECOND(), TIMENOW(), and TIMEVALUE(). These functions empower you to perform calculations and make decisions based on time data within your flows. Previously, extracting and manipulating time in Date/Time fields was very difficult, and it involved parsing text values that contained this information.

Important Considerations

• The Time data type is currently not supported in the offline flows available on the Salesforce Mobile app.
• This change applies to flows running on API version 64.0 or later. If you have existing flows created with API version 63.0 or earlier that use custom fields of the time data type, they will continue to work as before. However, to leverage the full functionality of the updated time data type in those flows, you’ll need to edit them and save them as a new version configured to run on API version 64.0.

Random Number Generation

One benefit of the new time-related capabilities is that you can use the new functions to generate random numbers. There is no random number generator function available in flow. Previously, I extracted the seconds out of a Date/Time value to generate a random number, now I can generate one using the Milliseconds.

Select multiple leads on a data table to add them to a prize drawing. Generate a random number and determine the winner. Email the winner to communicate the prize they won.

For this use case I leveraged many new flow functionalities.

Let’s get right to the build.

Build the Screen Action Autolaunched Flow

The selected leads can span over several screens in the data table, when the user is completing their selection. I decided to use an autolaunched flow to compile a CSV list of lead names which will be shown under the data table, as the user is completing their selection.

For that I build an autolaunched flow. Follow these instructions to build yours:

1. Start an autolaunched flow.
2. Create a Lead Collection Record Variable and make it available for input.
3. Create a Name CSV Text Variable and make it available for output.
4. Use the transform element to extract a text collection variable of names (first names) out of the lead collection record variable (not required, I wanted to use this new feature).
5. Loop the names collection text variable.
6. Add an assignment to add the current name text, and then a comma and a space character to the Name CSV Text Variable.
7. Outside the loop add another assignment to assign a new value to the Name CSV Text Variable. This new value will be the accumulated names in csv format with the last comma and the space character removed. Use a formula resource to compute the value. The formula is: LEFT({!NameCSVTextVar},LEN({!NameCSVTextVar})-2)
8. Debug, save and activate the flow.

Build the Screen Flow

Follow these instruction to build your flow:

1. 1. Start a screen flow.
   2. Get the leads in the org where the email is no null (limit the get to 2,000 records not to hit limits).
   3. Add a screen. Place a data table on the screen showing the leads, and allow for multi selection. Add a screen action to the screen and point it to the autolaunched flow you created above. Pass the Lead Data Table Selected Rows to the screen action autolaunched flow as input.
   4. Assign the count to a Count Number Variable (no decimals). Also assign the winner number to a Winner Count Variable. This is to ensure that the number does not change in debug (I don’t think it will change in production execution). You will need a formula resource to determine the winner. Here is what this formula does: Generate a number between 1 and 1,000 using the milliseconds value of the time of the execution, and prorate that using the number of leads the user selected to determine the winning number. Assign the following formula value to the Winner Count Variable:ROUND(((MILLISECOND(TIMENOW())+1)*{!CountLeadsVar}/1000),0)+1
   5. Loop the Lead Data Table Selected Rows and assign a value incremented by 1 to a counter variable in every iteration (CounterVar Add 1).
   6. Check Via a decision whether the winning number is equal to the counter variable.
   7. If the winner is determined assign the Lead Record to the Winning Lead Record Variable, and exit loop. If not, keep looping.
   8. Outside the loop send the email to the email address of the winning lead and congratulate them. I built my email template with inside the brand new email action element for this one (Summer ’25).
   9. Debug, save and activate the flow.

Please note that, I tried conditionally running the screen action only after the user selects the first data table row, but that functionality (Summer ’25) does not seem to work properly in preview. I have a ticket open with Salesforce to determine whether that is a bug.

If you want to see the flow in action, watch this video.

Conclusion

The introduction of the Time data type is a significant step forward for Flow, enabling more precise and efficient time-based automation. It’s one of the many high-impact features and quality-of-life improvements packed into the Summer ’25 release that are bound to make your job easier.

Ready to give it a spin? Don’t forget to sign up for a pre-release org to test out this and other new features! You can also find more details in the Summer ’25 release notes.

Explore related content:

Salesforce Summer ’25 Preview: Major Flow Changes to Watch For

Time Zone and Time Operations in Flow

Supercharge Your Approvals with Salesforce Flow Approval Processes

#AutolaunchedFlow #DecisionElement #GetRecords #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #Summer25 #Time #TimeDataType

Error Busters: Guide to Solving Flow and Apex Trigger Errors in Salesforce

Hey there, fellow Trailblazers! Ever hit a snag with a Flow or an Apex trigger and felt like you needed a magnifying glass and a detective hat? You’re not alone! Errors happen, but luckily, Salesforce gives us some fantastic tools and strategies to figure out what went wrong. Think of troubleshooting less like a chore and more like some fun detective work.

Last week I attended MidAtlantic Dreamin where I presented on this topic. You can download my slides using the link on the bottom of this page. But before that, let me give you an overview of the content.

Here are my tips for solving flow and Apex trigger errors in Salesforce.

Starting Your Detective Work: The Essential First Steps

When an error pops up, don’t panic! Take a deep breath and start with the basics:

1. Read the Error Message Carefully:This might sound obvious, but error messages are your first clue! For Flows, check the error message at the top and bottom of any fault emails you receive – they can be super descriptive. For Apex, you’ll get unhandled exception emails; make sure to read these closely too. Sometimes the message itself tells you exactly what happened.
2. Inspect Your Test Data: Make sure the data you’re using for testing is appropriate. If you’re working with Flows, try not to reuse old records. Why? They might have weird field value combinations due to recent changes in automation or validation rules. For Apex, your test classes should generate appropriate test data.
3. Become a Debug Log Pro: The debug log is your absolute best friend! It shows you exactly what happened during the execution of your Flow or Apex trigger. For Flows, try reading the log like a book from top to bottom to trace the path. For Apex, the log shows variable values and exceptions. You can set up a detailed user trace for the user running the automation to capture all the gory details.
4. Check Fault Emails (and Failed Flow Interviews): If a production Flow fails and doesn’t have a fault path (more on those later!), an administrator or the creator gets a fault email. This email is golden! It has a link directly to the failed interview, showing you a stop sign icon, and often highlights the failing element. You can also check the Paused and Failed Flow Interviews screen in Setup for details and debug log links. Apex failures send unhandled exception emails. Read those emails carefully.

Flow-Specific Super Skills

Flows have some unique debugging powers. Make sure you use them!

• Debug As You Build: Don’t wait until your Flow is a giant spaghetti monster! Debug it in meaningful parts right after saving each section. This keeps the debug log manageable and helps you catch issues early.
• Use the Flow Debugger Extensively: This built-in tool is fantastic! You can skip start conditions, run as a different user (great for checking permissions!), and inspect variable values at every step.
• Look for Stop Signs: When debugging, if you see a stop sign, that means an error happened during that debug run. Also, make sure the path followed is highlighted all the way to the end for a successful execution.

• Test Activated Flows in a Sandbox: Debugging is awesome, but the real test is when the Flow is activated and running in a sandbox environment. This simulates production better.
• Understand Transaction Boundaries: Be aware that errors in one part of a screen Flow transaction might not roll back changes from a previous successful step unless you use a Roll Back Records element. This is especially important with screen Flows and data manipulation. Know that you may get a partial save and commit for collection operations, when using the fault path in a flow.
• Reverting Versions: If an error started happening after a recent change, consider reverting to a previous working version. Sometimes, a Flow can even become corrupt and you might need to clone a working version or build a new one.
• Scheduled Path Flow Testing: For these, debug each scheduled path separately. When initially testing, set the schedule to run one minute later for quick results. You can monitor pending actions in the Time-Based Workflow screen.

Apex Trigger Troubleshooting Tactics

• Isolate the Trigger: If you have several triggers on the same object, try to figure out which one is causing the error.
• Review Your Logic: Go through the code carefully, looking at conditions, loops, and DML operations to pinpoint the source of the error.
• Consider a Trigger Handler Framework: If you have many triggers on an object, using a framework can help manage and orchestrate them, making isolation, testing and debugging easier.

Tips for Both Flows and Apex: The Universal Rules

• Master the Order of Execution: Salesforce has specific steps it follows when a record is saved. Understanding how Flows, Apex, Workflow Rules, and Process Builders interact is crucial. Knowing the order helps you find conflicts.
• Respect Governor Limits: Salesforce sets limits on things like how many SOQL queries or DML operations you can do in a transaction. Going over these limits causes errors! A common mistake is doing operations inside loops. Flows and Apex even have some separate limits (e.g. scheduled jobs).

• Simplify or Isolate Complex Automation: If your automation is huge and complicated, try breaking it down or isolating the specific part where you think the error is happening.
• Check Permissions and Access: Does the user running the Flow or trigger have the right permissions for the objects and fields involved? Test running Flows as different users to check this.
• Look at Related Automation: Sometimes, an error in your Flow or trigger is actually caused by a validation rule or another piece of automation running on the same object. Deactivate or examine related automation to see if they’re the culprits. Using Custom Metadata Type switches can help with temporarily disabling automation for testing (see Using Custom Metadata Types in Flows Without Get).
• Search Online! If you get a weird error message, chances are someone else has seen it before! Search Salesforce forums, Stack Exchange, and other communities. Leverage AI LLM models.
• Ask for Help: Don’t bash your head against the wall alone! Collaborate with other admins or developers. Sometimes a fresh pair of eyes is all you need. Join the Flownatic Slack Workspace.

Is Your Salesforce Flow Too Big?

#Apex #ApexTrigger #Debug #MidAtlanticDreamin #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

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

Start Autolaunched Flow Approvals From A Button

Salesforce Flow Approval Process revamp was a success. When I look at all the interest I see from the ecosystem, there is a significant number of automation experts experimenting with this feature, and building approvals.

The new approval process is built on Orchestration, and it is free. There are two types of approval processes you can create:

• Record-Triggered
• Autolaunched

I covered the record-triggered use case with the recent Supercharge Your Approvals with Salesforce Flow Approval Processes post. Let me give you another use case where the user can start an autolaunched approval process from a button. I have incorporated the answers to a few questions I recently received into this build.

Escalate a case to a queue of level 2 experts when a second opinion is required.

Start Flows and Orchestrations From a Button

• Quick actions can only be used to add an active screen flow to the page layout. Remember that you are not required to add a screen element to your flow, but your flow has to be saved and activated as a screen flow. Orchestrations are not supported.
• The record Id of the current record on the screen will be automatically passed to the recordId variable. The variable name in the screen flow has to follow this exact syntax.
• You can not pass additional input parameter values into your automation.

When you build autolaunched approval process, you build autolaunched automation that can be executed on demand. This is very similar to the autolaunched Orchestration or flow. Although this autolaunched automation can and will have UI components like approval evaluation step screen flows, they can not be called from a quick action button.

As a result, we will build an autolaunched Approval Orchestration and assign it to a button using the URL method. I will explain how we will do that after we complete the build.

Build an Approval Screen Flow From The Template

Use the Approvals Workflow: Evaluate Approval Requests template to build your screen flow. When sent to approval, your case will show this screen flow as a work guide item on the lightning page layout.

1. Create New Flow.
2. Choose Template.
3. Pick the Approvals Workflow: Evaluate Approval Requests template.
4. Make cosmetic modifications and save your flow and activate it. You can also add additional inputs and screens for your users to submit data, if you need that.

Please note that this template includes all the required variables with the required syntax: approvalDecision and approvalComments. You can build your own screen flow without starting from a template, but then you will have to make sure you complete this required step manually.

Build an Autolaunched Approval Orchestration (No Trigger)

Now that you built the required screen flow, you can build your approval orchestration that will call this screen flow.

For this example, create a queue called Level2 for cases. Add yourself to the queue and assign an email address to the queue that you use for testing purposes.

1. Create New Flow.
2. Choose From Scratch.
3. Choose Autolaunched Approval Orchestration (No Trigger) from the list of boxes you see on the screen.
4. Add a stage. You don’t need to configure the start element for this type of Orchestration.
5. Add a step. Point it to the screen flow you have saved and activated.
6. Scope the approval to the Case recordId. This is where the work guide item will appear for the approvers.
7. Assign the approval to the queue you created (Level2). Lock the record for all, do not customize the email.
8. Save and activate your approval orchestration.

Configure the URL Custom Button

Go to your all flows list view and choose View Details and Versions under the list view line item chevron menu on the right side. Grab the URL for your Orchestration. It should look like this (depends on your naming): /flow/Case_XPR_Approval_AL_Orchestration

Use the required syntax to add the URL for the approval orchestration to the button. Here is the syntax for my orchestration (view the Salesforce documentation here):

/flow/Case_XPR_Approval_AL_Orchestration?recordId={!Case.Id}&submitter={!$User.Id}&retURL={!Case.Id}

Note that the first part is the URL you just grabbed, and the following parts are the input parameter values for the orchestration. The last parameter directs the screen to the case when the automation is completed.

Follow these steps to add this button to the case record page:

1. Go to Setup > Object Manager > Case > Buttons, Links, and Actions and add a New Button or Link
2. Give your button a label (I will call it Case Approval button here), make it a Detail Page Button, display it in existing window (one of the choices), and choose URL.
3. Paste the URL you built for your approval orchestration into the URL window and check the syntax. Save it.
4. Go to page layouts under the Object Manager, and add the custom button to the page layout in use.
5. Go to the lightning page layout editor for the layout in use and add the Case Approval custom button there. Save and activate (no need if it is active) the page layout.

Add the Flow Orchestration Work Guide Component

While you are on the lightning page layout editor, add the Flow Orchestration Work Guide component to the case lightning page layout. It works well on the top of the right column. Save your page layout. This component will show the work guide item to the users when the approval step is assigned to them. I recommend you choose to hide the component when there is to work guide item assigned to the user.

Add the Approval Trace Component

The related lists for legacy approvals won’t show the flow orchestration approval progress for the record. You need to add the Approval Trace component to the page layout for that. Edit the page layout for case, and drag the Approval Trace component to your case lightning page layout. I recommend you create an additional tab for this and add the component there.

Remember that you can see all the approval process information for all your records on the Approvals Lightning App.

Activating Email Response Approvals

Watch the Video for a Full Tutorial

Watch this video to learn how I built an Autolaunched Flow Approval Orchestration and assign it to a button on the Lightning Record Page. This solution shows how you can use queues to assign your approval step. In addition, you can see what email notifications are being sent for approvals, and how approval email responses can be leveraged to complete the approval step.

Explore related content:

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

Keep Salesforce Data Clean With Before Save Flows

Transform Element Now Supports Join Collections

Tom Bassett’s YouTube Channel

#ApprovalProcesses #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #UI

Supercharge Your Approvals with Salesforce Flow Approval Processes

Are you finding that as your company grows, the complexity of your approval workflows grows along with it? What once might have been a simple sign-off from a single manager can quickly transform into a multi-step process involving input from multiple departments, stakeholders, and even external partners. This complexity often leads to delays, inefficiencies, and frustration as approvals get stuck in bottlenecks or lost in email chains. 

Does this sound familiar? Read on for a new solution! 👇🏼

Introducing: Salesforce Flow Approval Processes 

With Salesforce Spring 25 release, discover a revamped feature designed to automate even the most intricate approval workflows. With Flow Approval Processes, you can create approval orchestrations (multi-step processes that interact with multiple users and systems) ensuring that approvals are handled efficiently, no matter how complex they become.

In this blog post, we’ll discover Flow Approval Processes, exploring how they work, when to use them, and how to get started. We’ll also cover key concepts, best practices, and troubleshooting tips to help you make the most of this feature.

What Are Flow Approval Processes?

Flow Approval Processes are part of Salesforce’s Flow Orchestrator, a tool that allows you to automate complex business processes. An approval orchestration is a sequence of stages, each containing one or more steps, designed to review and approve a specified record. These stages can include:

1. Approval Steps: Assign approval tasks to users, groups, or queues.

2. Background Steps: Automate actions related to the approval process without requiring user interaction.

I know that orchestrations are consumption based paid automation solutions that offer a free limited tier. FLow approval processes based on Orchestrations are entirely free. If you have access to legacy approvals, you can use this new tool at no additional cost.

A new vendor contract needs approval from the legal team, the finance department, and an external partner. With Flow Approval Processes, you can create an orchestration that automatically routes the contract to each stakeholder in the correct order, sends reminders, and updates the record once all approvals are complete.

Key Features and Benefits of Flow Approval Processes

1. Multi-Level, Multi-User Approvals

Flow Approval Processes are ideal for workflows that require input from multiple people across different departments or even outside your organization. Whether it’s a budget approval, a marketing campaign, or a new product launch, you can design an orchestration that ensures every stakeholder has their say.

2. Integration with External Systems

This functionality aids in automating business processes by enabling integration between Salesforce orchestrations and external systems, ensuring that complex workflows can pause, wait for external input, and then resume automatically.

3. Dynamic Logic and Decision-Making

Not all approvals follow the same path. Flow Approval Processes allow you to use decision elements to create conditional paths based on specific criteria. For example, if a contract exceeds a certain dollar amount, it might require additional approvals from senior management.

4. Email Notifications and Work Guides

Approvers receive email notifications with links to the records they need to review. They can either click the link to access the Work Guide in Salesforce or reply directly to the email with keywords like “Approve” or “Reject” to complete their action.

5. Scalability and Flexibility

Whether you’re a small business or a global enterprise, Flow Approval Processes scale with your needs. They’re available in Enterprise, Performance, Unlimited, and Developer Editions, as well as in Government Cloud and Government Cloud Plus.

6. Brand New UI and Audit Trail

Flow Approval Process brings a new lightning app to your Org titled Approvals. Every Step and Stage are well documented in the new data model that comes with the new functionality using objects, such as Approval Submissions, Approval Submission Details, Approval Requests and Approval Work Items.

When to Use Flow Approval Processes

Flow Approval Processes are particularly useful in scenarios where:

1. Multiple Approvers Are Involved: When approvals require input from several people in a specific order.

2. External Stakeholders Are Part of the Process: When approvals involve partners, vendors, or customers outside your organization.

3. Complex Logic Is Required: When different conditions or criteria determine the approval path.

4. Time Zones and Availability Are a Factor: When approvers are located in different regions or have varying schedules.

Get Started with Flow Approval Processes

✅ Step 1: Understand the Requirements

Before getting into building an approval orchestration, it’s essential to consult with stakeholders to understand the approval workflow’s requirements. What steps do you need to take? Who needs to approve what? Are there any conditional paths or external systems to consider?

✅ Step 2: Build the Approval Orchestration

Using Salesforce Flow, you can create an approval orchestration by defining stages and steps. 

Each stage can include:

Approval Steps: Assign tasks to users, groups, or queues.

Background Steps: Automate actions like updating records or sending notifications.

You can also use decision elements to create conditional paths based on specific criteria.

✅ Step 3: Add the Work Guide Component

Before activating your approval orchestration, an admin adds the Flow Orchestration Work Guide Lightning App Builder component to the page layout for the record type under review. This component provides approvers with a centralized interface to view and complete their tasks.

✅ Step 4: Test and Activate

Once you build your orchestration, thoroughly test it to ensure it works as expected. After testing, activate the orchestration to make it available for use.

Key Concepts to Know

• Approval Orchestration: A sequence of stages and steps designed to review and approve a record.
• Approval Submission: The process of submitting a record for approval, which triggers the associated approval orchestration.
• Approval Work Item: Task assigned to an approver as part of an approval step.
• Orchestration Run: An approval orchestration executes for a specific record.=

Build a Simple Flow Approval Example

A multinational company uses Flow Approval Processes to manage opportunities with an amount larger than $10 million, ensuring that the high amount opportunities are checked and approved by management. This ensures that proper reviews are completed before the sales and forecast reports are distorted with unrealistic sales pipeline items. Create a task related to the opportunity that shows the record has been approved.

Orchestrations are automations that stitch together flows. Therefore you need to prepare your flows first.

1. Create the approval screen flow that will be displayed on the lightning record page work item component. Use the Approvals Workflow: Evaluate Approval Requests flow template in your Org to create your flow. You can leave the design mostly unchanged. Give your flow a label and save and activate. If you create your own modified version, you will need to create and populate these standard output variables:
   • approvalDecision – A text output variable populated with ‘Approve’ or ‘Reject’ depending on the outcome.
   • approvalComments – A text output variable that will hold the freeform comment entry by the user.
2. Create an autolaunched flow that will create the task. Define two input variables, save and activate your flow:
   • Opportunity Id Variable – Opportunity Id for the record that triggered the orchestration for the approval
   • Description Variable – The input variable to assign a value to the task description. You can pass the approval comments into this variable.
3. Build a Record-Triggered Approval Orchestration from scratch. Trigger your orchestration when a new opportunity record is created with an amount greater than $10 million. Remember to keep the checkbox set to true for record locking. You can choose to customize the email communication that goes to the users. Your orchestration should look as follows.

Save and activate your orchestration and test it in your sandbox environment before full deployment.

Here are a few screenshots that show how the approval looks in your Org.

This slideshow requires JavaScript.

Troubleshooting and Management

Handling Failed Submissions

If an approval submission fails, the associated orchestration run also fails, and the system sends a fault email. To troubleshoot, review the details in the fault email and check the orchestration run logs.

Managing Submissions and Work Items

Use list views to manage approval submissions and work items. You can recall a running submission or reassign incomplete work items to another user.

Deploying Your Approval Orchestration

After designing and testing your approval orchestration, deploy it. Inform all stakeholders about the new process and provide training if needed. Monitor the orchestration’s performance and make adjustments as needed to optimize efficiency.

Conclusion

Salesforce Flow Approval Processes are a game-changer for businesses looking to improve their approval workflows. By automating multi-step, multi-user processes, you save time, reduce errors, and handle approvals consistently and efficiently.

Additionally, whether you’re managing vendor contracts, employee expenses, or marketing campaigns, Flow Approval Processes provide the flexibility and scalability you need to keep up with your growing business.

Ready to get started? Explore this Flow Approval Processes link to learn more about the limitations and capabilities in Salesforce’s official release documentation. Looking for a course on the subject? Flow Canvas Academy opened a NEW Flow Approvals Crash Course. Check it out HERE.

Watch the demo on the Salesforce Break YouTube channel 👇

Explore related content:

Transform Element Now Supports Join Collections

Top 7 Salesforce Spring 25 Flow Features

How To Use Custom Permissions In Salesforce Flow

Start Autolaunched Flow Approvals From A Button

TDX 2025 News: Salesforce Agentforce 2dx and AgentExchange

#ApprovalProcesses #LowCode #Orchestration #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

How To Use Custom Permissions In Salesforce Flow

Custom Permissions in Salesforce are a powerful feature used to control access to specific functionality or features within your Salesforce Org for Validation Rules, Flows, and Apex code. They provide a flexible way to manage user permissions beyond the standard object or field-level security. You can use them as a switch or toggle to control your automation.

Key Features of Custom Permissions

1. Granular Control: Custom Permissions allow you to define access to specific app features or processes without relying solely on profiles or permission sets.
2. Dynamic Use Cases: They can be used to switch access on and off for custom functionality like buttons, Visualforce pages, Lightning components, or Apex code.
3. Hierarchical Configuration: You can assign custom permissions through permission sets or profiles, giving flexibility in managing user access across different roles.

Common Use Cases

1. Feature Activation: Control whether a user can access specific features in an app.
2. Process Visibility: Show or hide parts of a process, such as a button or field, based on whether a user has the associated custom permission.
3. Conditional Logic: Use in Apex, Validation Rules, or Flows to conditionally execute logic based on whether the current user has the custom permission.

Benefits of Salesforce Custom Permissions

• Modularity: Decouples feature access from broader permissions, simplifying configuration.
• Efficiency: Simplifies permission management when features are tied to multiple user roles.
• Reusability: Enables scalable access control that can adapt as your organization grows.

Your organization adheres to a strict release schedule, requiring the deployment of a record-triggered flow today. However, activation of this flow should occur in one week without your direct involvement.

Solution: Create a custom permission and assign it to a permission set. Assign the permission set to all users. Add to the entry criteria for your record-triggered flow that the running user must not have the custom permission for the flow to execute.

Here is how it is done:

Creating and Using Custom Permissions

1. Create Custom Permission

• Go to Setup > Custom Permissions > New.
• Define the name and description for the custom permission.

2. Assign to Users

• Add the custom permission to a Permission Set (or Profile).
• Assign the permission set to all users. Remember that you can assign permission to only a few users or groups (granular control) if your use case calls for it. Define an expiration for the assignment: the permission set must be scheduled to be removed in a week.

Build your flow

1. Build a record-triggered flow. For example, a flow that sends out an email.
2. Add to your start element criteria (Remember this will be true when the custom permission is not present.                       The toggle will be on.): NOT({!$Permission.CustomPermissionName})
3. Test, debug, and deploy your flow. Make sure it is active.

By using Custom Permissions, you can assign granular feature access and enhance security while maintaining flexibility.

Other Use Cases for Custom Permissions:

• Validation Rules: NOT($Permission.CustomPermissionName)
• Apex Code: FeatureManagement.checkPermission(‘CustomPermissionName’)
• Lightning Components or Buttons: Conditionally display based on user access.

Conclusion

Custom permissions in Salesforce offer a versatile solution for managing complex access controls within your org. By enabling granular, dynamic, and hierarchical access management, they allow you to fine-tune how features and functionalities are deployed and utilized across different user roles. Whether you’re looking to activate specific features, manage process visibility, or implement conditional logic in your applications, custom permissions provide the flexibility and scalability needed to address these requirements effectively. As demonstrated with the record-triggered flow use case, integrating custom permissions into your Salesforce setup not only enhances security but also ensures operational efficiency and adaptability to evolving business needs. By utilizing this feature, Salesforce admins and developers can ensure that their org’s environment remains both secure and precisely tailored to their specific operational demands.

Explore related content:

Using Custom Metadata Types in Flows Without Get

How to Use Custom Metadata Types in Flow

15 Effective Salesforce Flow Debug Strategies

Flow Naming Convention Tips

Profiles and Permissions in Salesforce: The Simple Guide for Admins

#Admin #CustomPermissions #Developer #PermissionSet #Salesforce #SalesforceTutorials #Trailblazer #useCase

Keep Salesforce Data Clean With Before Save Flows

Data quality is essential for every Salesforce administrator, as it influences reporting accuracy, decision-making, and overall user confidence. With users constantly inputting data through multiple interfaces, maintaining clean, standardized field values is an ongoing challenge. Fortunately, Salesforce provides tools like validations, reports, batch updates, workflow rules, and processes to help manage data consistency. The introduction of before-save flows in the Spring ’20 Release has transformed data handling, allowing admins to update field values as records are created or modified—without needing complex code. This guide will explore how before-save flows can help streamline data entry, reduce errors, and ensure clean, accurate field values across all data channels.

There are several tools available in Salesforce to ensure clean data:

• Validations
• Reports
• Batch updates
• Workflow rules
• Flows
• Code

Salesforce administrators have the functionality to update field values by triggering a before-save flow when a record is created and/or updated. Admins do not need to write code to start the update.

Understanding The Before-Save Flow Execution

Before we go into the details of the use case and the solution, let’s dissect and understand what this all means. When a user creates or updates a record there are several steps that are executed while the data is being written to the database. When we use popular automation tools and trigger an update on the fields, what typically happens is that the data the user provides is saved, and then overwritten based on the automation rules that are implemented in the system. This update method is not very fast, and presents several potential complications: Duplicate rules can kick in based on the data that is initially entered into the system and produce unexpected results, although the final data saved based on the active automation rules may not trigger the same duplicate rule.

Advantages of Before-Save Flow Updates

Before-save updates are executed before the data is saved; very early in the order of execution. This makes them very fast, and also more predictable because there is a lower chance that they produce unexpected results interacting with other automation rules.

Another advantage of before-save updates is that they are executed regardless of what channel the update is coming from. You may have internal users entering data on Salesforce. You may also have external users entering data on a flow that runs on a digital experience (community) site. If you use field validation rules, you will need to set them up separately on all channels. When you set up a before-save flow update, on the other hand, it will be executed whenever the data is entered and/or updated regardless of the channel.

Examples of Before-Save Flow Applications

🚨 Use Cases 👉🏼 What is this solution good for?

• Clean special characters from phone field entry on the contact
• Update custom record name combining several field values on the same object
• Update accounts based on employee count and categorize them by Small/Medium/Large

Main limitations:

• The flow operations that can be performed are limited (please see the image).
• Before-save flows can not perform create or update operations on the related objects and their fields.

Clean Special Characters From Phone Entry

I built a solution for volunteers to check-in on a digital experience site using their mobile phone number. One potential issue with this flow is that the users enter phone numbers into the system in various formats. For example, these entries are very common:

• 5555555555
• 555 555 55 55
• (555) 555-5555

You can easily write a SUBSTITUTE formula to strip the special characters and spaces out of these entries.

This means that you can build a very simple formula to take the phone data entry value, and replace it with a new value before it is committed to the database. The new value will be in the format of the first bullet above.

The Flow

Start a record-triggered before save flow.

The flow consists of two elements only: The start element and one assignment element. Please remember that there is no need for a get or update element. We are working with the value that is entered on the screen and assigning a value to what will be written to the database.

Please note that I recommend using the update element before save instead of the assignment element currently, although the functionality is the same.

The first step on our flow will be to adjust the settings on the start element. When the start element is double-clicked, the flow editor displays several settings that can be adjusted. In this example, we would like to launch our flow when a contact record is created or updated to make fast field updates.

The second element in the flow is a simple assignment element. {!Record.MobilePhone} refers to the mobile phone field on the contact record that the user is about to create or update. This step assigns a formula value to the mobile phone field.

The Formula

Here is the {!CleanMobilePhone} formula:

SUBSTITUTE(
SUBSTITUTE(
SUBSTITUTE(
SUBSTITUTE({!$Record.MobilePhone} , "(", ""), ")", ""), " ", ""), "-", "")

It is a simple formula that finds the ()- and space characters in a string and removes them.

The Result

When this flow is saved and activated, it updates all mobile phone entries before they are saved to the database. The field value will only consist of digits. Please remember that Salesforce formats the phone fields for display purposes on the screen. You will see (555) 555-5555 displayed on the screen, but when you go to edit the field, you will find out that the value only includes digits.

Enjoy.

Explore related content:

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

6 Things You Can Do With The Transform Element

Create by Checking a Matching Record in Flow

Are You Using the Cut Functionality?

Fast Field Updates or Actions and Related Records in Record-Triggered Flows

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

Salesforce Flow validation rules are essential for ensuring data accuracy and consistency in automated workflows. By setting specific conditions that data must meet before it is saved or processed within a flow, these rules prevent erroneous or incomplete information from moving forward in the workflow. For instance, you might create a validation rule that requires certain fields, such as phone, email and address, to be filled out or ensures that a value falls within a specified range before the flow can continue. This not only enforces data quality standards but also helps avoid downstream errors that could disrupt business processes or lead to poor decision-making. With flow validation rules, Salesforce admins can maintain control over data integrity while enhancing user experience by proactively catching errors.

Below are a few popular flow validation rules I used in my projects

Name

Standard length for Name Fields is 40 for First Name, 20 for Middle Name and 80 for Last Name.

First Name

Error message:

Your entry needs to be shorter than 40 characters.

Validation rule:

LEN({!First_Name})<=40

Social Security Number (USA)

Error message:

Please enter 9 digits for the SSN field.

Validation rule (this rule allows for dashes):

OR( 

REGEX( {!Social_Security_Number} , "[0-9X\-]{11}"), 

REGEX( {!Social_Security_Number} , "[0-9]{9}") 

) 

Address

Standard length for address fields are 256 for Street Address and 80 for City. The ZIP (Postal) code can be in XXXXX or in XXXXX-XXXX format (USA).

State Code

Error message example:

Please enter a State Code consisting of two capital letters.

Validation rule:

NOT( 

 AND( 

   NOT(ISBLANK({!State})), 

   OR( 

      LEN( {!State}) <> 2, 

      NOT(CONTAINS({!State}, UPPER({!State}))) 

    ) 

 ) 

) 

ZIP (Postal) Code (USA)

Error message example:

ZIP code needs to be in XXXXX or in XXXXX-XXXX format.

Validation rule:

REGEX({!MailingZIP} , "\d{5}(-\d{4})?")

Revenue

Error message example:

Your entry needs to be shorter than 16 digits.

Validation rule (Currency upper limit):

{!Revenue}<10000000000000000

Email

Error message example:

Please enter a valid email address.

Validation rule:

REGEX({!Email_Address},"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}")

Phone number

Error message example:

Please enter a 10 digit phone number.

Validation rule:

AND( 

LEN({!Mobile_Phone})=10, 

NOT(REGEX({!Mobile_Phone} ,"^[a-z A-Z]*$"))) 

Incorporating Salesforce Flow validation rules into your automated workflows can be transformative for maintaining data accuracy and enforcing business standards. These rules not only ensure that critical data points like names, social security numbers, and contact information meet required formats but also prevent incomplete or invalid entries from progressing through your system. By using validation rules to define acceptable data criteria, you create a more reliable, error-resistant environment that supports both user confidence and data integrity. 

Explore related content:

6 Things You Can Do With The Transform Element

Top 9 Salesforce Winter 25 Flow Features

Enhance UX in Flow with Custom LWC Icon Selector

Standard or Custom Object – The Importance of the Data Model