Beyond the URL Button: The Salesforce Request Approval Lightning Component

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.

Salesforce’s free Flow Approval Processes, built on Flow Orchestrator, automate even the most intricate workflows. A previous post explored launching these Autolaunched Approval Orchestrations via a custom URL button. Today, we are taking that functionality a massive step forward. We will explore the new Request Approval Lightning component and its tie-in to autolaunched flow functionality. This component expands automation by allowing dynamic user inputs directly from the record page.

The Foundation: Autolaunched Flow Approvals

Before diving into the new component, let’s quickly recap how autolaunched flow approvals function. When you build an autolaunched approval process, you are essentially building an autolaunched automation that can be executed on demand, very similar to an autolaunched Orchestration or flow. However, the traditional method of launching Salesforce automations (the quick action button) has strict limitations. Quick actions can only be used to add an active screen flow to the page layout; orchestrations are simply not supported. Furthermore, quick actions do not allow you to pass additional input parameter values into your automation beyond the standard recordId.

Because of these limitations, the standard workaround has been to build an autolaunched Approval Orchestration and assign it to a custom URL button on the page layout. For example, a common use case is to escalate a case to a queue of level 2 experts when a second opinion is required. By appending variables to the custom URL, such as ?recordId={!Case.Id}&submitter={!$User.Id}&retURL={!Case.Id}, administrators could successfully pass the necessary parameters to kick off the orchestration. While highly effective, this URL button method is a bit rigid. It automatically submits the record based on predefined flow logic without giving the submitter much runtime flexibility.

Enter the Request Approval Lightning Component

This is where the new Request Approval component completely changes the game. Instead of relying on a custom URL button to trigger your background orchestration, you can now add a native, user-friendly interface directly to your Lightning record pages. This component bridges the gap between the UI of a screen flow and the processing power of an autolaunched orchestration.

To utilize this feature, you must first design, test, and activate an autolaunched flow approval process. Once your flow is ready, you can simply open the record page where you want to place the component. Click the gear icon on the navigation bar, and select Edit Page to open the Lightning App Builder. From the Components tab, search for “Request” and drag the Request Approval component directly onto the layout.

Straightforward Setup

You can customize the title of the component to display user-friendly text at run time. Then search for and select your active, autolaunched flow approval process to run whenever the user clicks the “Start” button. You can also assign a specific label to identify the associated flow approval process to your users.

Expanding the Use Case: What Can Be Added?

So, how exactly does this new component expand the capabilities of your autolaunched flow use cases? The true power of the Request Approval component lies in its ability to gather critical, dynamic inputs directly from the submitter at the exact moment of submission. When using the old custom URL button method, the approver destination (such as the Level 2 expert queue) was hardcoded into the flow steps. With the new component, you can dramatically increase the flexibility of your processes through two main enhancements:

Dynamic Approver Selection

The component allows you to require submitters to actively select an approver before the flow runs. To enable this, you must configure your underlying autolaunched flow approval process to assign one or more approval steps to a specific resource named firstApprover. In the Lightning App Builder, you then select the Require submitter to select an approver setting.

It is critical to ensure your flow is properly configured to accept this input. Consider whether the flow approval process you selected assigns one or more steps to the firstApprover resource. If it does, you must select this requirement on the component to prevent the flow approval process from failing when a submitter attempts to use it. This means a single autolaunched flow can now be routed to entirely different managers, departments, or external stakeholders on the fly.

Submission Comments

Another massive expansion of your use case is the ability to capture submission comments. Often, an approver needs context as to why a record is being submitted. The Request Approval component shows an Approval Request Comments field by default. This exposes optional submitter comments directly to the approvers via the submissionComments resource.

If your business process dictates that comments are unnecessary, or if you want to streamline the UI to prevent the submitter from adding comments about a submission, you easily have the option to select Hide submitter comments within the component configuration. These comments are stored cleanly in the new data model under the Approval Submissions object, specifically within the Comments field, making them accessible via queries if you wish to display them in custom approver screen flows.

The Impact on Your Org’s Architecture

By tying the Request Approval component to your autolaunched orchestrations, you unlock a highly scalable and flexible architecture. You no longer need to build dozens of slightly different flows for different queues or approvers. Instead, you can rely on a single autolaunched flow that dynamically adapts based on the firstApprover and submissionComments variables passed from the component.

This ties seamlessly into the broader Flow Approval Process ecosystem. Once submitted, the process still leverages the brand-new UI and audit trail, including the Approvals Lightning app, Approval Submissions, and Approval Work Items. The orchestration sequences stages and steps behind the scenes. It potentially triggers automated background steps like updating records or sending notifications without requiring further user interaction. Approvers still receive their email notifications with links to the Work Guide, and they can still reply directly to the emails with keywords like “Approve” or “Reject” to complete their action. Furthermore, administrators must still remember to add the Flow Orchestration Work Guide component to the record page. It approvers have a centralized interface to actually interact with the assigned approval step.

It is important no note that this component allows the user to recall the approval process once it is started.

Conclusion

The Request Approval component takes the Autolaunched Flow Approval Process and makes it more dynamic and user-centric. By moving away from static URL buttons and embracing this native Lightning component, administrators can empower their users to select appropriate approvers and provide vital context through comments. All while leveraging the free, robust automation engine of Salesforce Flow Orchestrator.

Whether you are routing cases to level 2 experts or managing multi-million dollar contracts, this functionality ensures your approval workflows are as efficient, user-friendly as possible. Save and activate your record page layout, exit the Lightning App Builder, and watch your new approval processes in action.

Explore related content:

How to Build Custom Flow Approval Submission Related Lists

Start Autolaunched Flow Approvals From A Button

Supercharge Your Approvals with Salesforce Flow Approval Processes

Mastering Data Rollups in Nonprofit Cloud

Every forward-thinking organization wants to base their business management decisions on intelligence derived from accurate, real-time data. However, as any Salesforce professional knows, “accurate data” is often the result of sophisticated background calculations and complex statistics. Depending on your specific Salesforce environment, the tool you choose for these calculations can vary wildly. In a standard Sales Cloud environment, you might reach for a simple Summary Report or a Roll-up Summary field. But when you move into the world of Salesforce Industries (like the new Nonprofit Cloud – NPC, aka Agentforce Nonprofit), the decision-making process becomes significantly more complex. Suddenly, you have a massive arsenal of tools: the Data Processing Engine (DPE), the Business Rules Engine (BRE), OmniStudio, and of course, Salesforce Flow.

My golden rule is this: Always use the tool you already know if it fits the case at hand. While advanced tools like DPE are powerful, they often come with steep learning curves and license-based limitations. In this tutorial, I’m going to show you how to perform complex donor fulfillment calculations using Flow and the new Transform element, writing that data directly to the Account record in a way that is efficient, scalable, and easy to maintain.

In this scenario, we want to provide our fundraising team with a clear snapshot of a donor’s health directly on their Account page. Specifically, we want to calculate:

Current Year Gift Commitment: In the Nonprofit Cloud data model, this represents a donor’s promise or pledge. For example, if a donor promises to pay $100,000 over the next year, that commitment is tracked here.

Current Year Paid Amount: Total amount actually received via transactions. Transactions represent the actual financial record of money received. A single Gift Commitment can have multiple paid Gift Transactions associated with it as the donor makes payments over time.

Fulfillment Rate: The percentage of the commitment that has been paid.

Membership Level: A tiered categorization (Gold, Silver, Bronze) based on their actual payments.

Why Flow Instead of DPE?

Nonprofit Cloud (NPC), built on the Salesforce Industries (formerly Vlocity) architecture, represents Salesforce’s modern reimagining for nonprofits. Unlike the legacy Nonprofit Success Pack (NPSP), NPC runs on the core Salesforce platform, leveraging Person Accounts and purpose-built objects designed to support high-scale fundraising and program management.

NPC includes pre-built Data Processing Engine (DPE) calculations for Donor Gift Summary. Think of DPE as a “mini-ETL” (Extract, Transform, Load) tool built directly into Salesforce. It is designed to handle massive datasets, millions of records, performing joins, filters, and aggregations that would typically cause a standard Flow to hit governor limits. While robust, it presents two significant limitations for many organizations:

Flow provides a “Low-Code” alternative that is highly customizable and doesn’t count against your DPE hour limits, making it the perfect choice for on-demand or daily updates for mid-sized datasets.

Step 1: Building the Logic (The Auto-Launched Subflow)

We start by building an Auto-Launched Flow. By keeping the math in a subflow, we ensure that we can trigger the calculation from a button, a schedule, or even an automated trigger without ever having to rebuild the logic.

1. Defining Input Variables

We need three primary inputs to make this flow flexible:

• recordId: The Account ID we are currently processing.

• StartDate: The beginning of the date range (e.g., the start of the fiscal year).

• EndDate: The end of the date range (e.g., today).

Pro Tip: Use formulas to handle “Null” inputs. If the user doesn’t provide a StartDate, my formula defaults to January 1st of the current year using:

IF(ISBLANK({!StartDateVar}),DATE(YEAR({!$Flow.CurrentDate}),1,1),{!StartDateVar})

IF(ISBLANK({!EndDateVar}),{!$Flow.CurrentDate},{!EndDateVar})

2. Fetching the Data

We use two Get Records elements to gather our collections:

• Get Gift Commitments: We filter by the DonorId (matching our recordId) and ensure the EffectiveStartDate falls within our selected range.

• Get Gift Transactions: We filter for records for the same Donor where the Status is ‘Paid’ and the TransactionDate is within our range.

3. Aggregating with the Transform Element

The Transform element is a powerful addition to Flow Builder that allows you to map and aggregate data collections. It eliminates the need for the traditional “Loop + Assignment” pattern when calculating sums or counts, making your flows significantly more readable and efficient. This is where the magic happens. Instead of a loop, we add a Transform element.

• Source: The collection of Gift Transactions.

• Target: A currency (single) variable.

• Mapping: Connect the source collection to the target variable, select Sum, and choose the Amount field.

This method is “Bulkified” by nature and much easier to debug than traditional loops. We repeat this process for the Gift Commitments.

4. Categorization via Formulas

To determine the Membership Level, we use a Nested IF formula:

IF(ISNULL({!Sum_of_Paid_Transform}),"",IF({!Sum_of_Paid_Transform}<=50000,"Bronze",IF({!Sum_of_Paid_Transform}<=100000,"Silver","Gold")))

We also calculate the Fulfillment Rate as (number, not percentage):

100*({!Sum_of_Paid_Transform}/{!Sum_of_Commitments_Transform})

Step 2: Creating the User Interface (The Screen Flow)

Now that the logic is built, we need to expose it to the users. We create a simple Screen Flow and place it on the Account record page using a Quick Action.

Step 3: Automating with Scheduled Flows

While the “Calculate” button is great for one-off checks, you don’t want your data to go stale. This is the beauty of the subflow architecture.

We created a Schedule-Triggered Flow that runs every night at 8:00 PM.

• Object: Account

• Filter: All Active Donors.

• Action: It simply loops through the accounts and calls the same subflow we used for the button.

This ensures that every morning when the fundraising team logs in, their dashboards and Account views are perfectly up to date without them having to click a single button.

Advanced Considerations: Performance & Scalability

When deciding between real-time (Record-Triggered) and batch (Scheduled) processing, consider your data volume:

• Real-Time: If you trigger this every time a GiftTransaction is created, it provides the most “Live” data. However, this could have performance implications.

• Batch: Running this nightly is the safest and most efficient way to handle large volumes of data without impacting the user experience during business hours.

Troubleshooting Common Issues

• Null Values: If a donor has zero transactions, the Transform element might return a null. Always ensure your formulas handle null values.

• Currency Conversion: If your org uses Multi-Currency, ensure your Get Records and Transform elements are looking at the “Converted” currency fields to maintain accuracy across different regions.

Conclusion: The Power of Low-Code

The introduction of the Transform element in Flow Builder has significantly narrowed the gap between standard Flows and high-performance tools like the Data Processing Engine. For most Nonprofit Cloud and Industry users, Flow provides the perfect balance of ease of use and computational power.

By centralizing your logic in a subflow, you create a “single source of truth” for your calculations, whether they are triggered by a user, a schedule, or a system event. In Nonprofit Cloud, this approach is especially valuable, where fundraising, commitments, and transaction data must stay tightly aligned across multiple purpose-built objects. This not only makes your org easier to manage but also ensures that your business decisions are always backed by the most reliable data available.

[youtube https://www.youtube.com/watch?v=fUvb2a1mpEc?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]

Explore related content:

The Ultimate Guide to the Salesforce Screen Flow File Preview Component

What Nonprofits Taught Me About Building Salesforce for Humans, Not Just Systems

New Trailhead Badge: Accessible Salesforce Customizations

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:

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):

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

Top 7 Key Takeaways from Salesforce Dreamforce 2025

Salesforce Break reviewed the press releases and sessions coming out of Salesforce Dreamforce 2025, and prepared the ket takeaways in this post, so you don’t have to go thorough all the materials.

The biggest announcements for Salesforce at Dreamforce 2025 were centered on advancing the company’s foundational “Agentic Enterprise” vision through enhanced control, deeper context integration, and widespread collaboration tools.

The announced functionalities were more evolutionary than revolutionary.

Here is the list.

Top 7 Key Dreamforce Takeaways

1. Agentforce 360 Platform, New Agentforce Builder, and Agent Script

The cornerstone announcement was the launch of Agentforce 360, the latest version of the comprehensive platform designed to unify AI, trust, and data capabilities across all Salesforce products. Salesforce has completely reimagined the entire Customer 360 platform as Agentforce 360, ensuring that every app is now “agentic”. This platform emphasizes providing users with more control than ever over their AI systems. To make development accessible to a wider audience, including line-of-business leaders, IT teams, service, and sales teams, a brand new AgentForce Builder was introduced, featuring a radically simplified, clean, and beautiful interface built from the ground up.

This capability is powered by Agent Script, a new scripting language that exposes the reasoning engine and allows users to define deterministic chaining actions and conditional logic. Agent Script unlocks patterns needed for mission-critical use cases, blending fluid agentic reasoning with the certainty of rules-based control in a unified instruction set to ensure agents are predictable and stay “on track,” preventing costly unpredictability. Agent Script can be built at the topic level where previous LLM-based non-deterministic functionality produced unpredictable results.

In addition, Salesforce announced Slack as its future conversational interface. Several sessions demonstrated deeper integrations in action. Another major change of course was the ability to use external LLMs for the Atlas Reasoning Engine. I believe this demonstrates that Salesforce is positioning Agentforce more as an orchestrator and collaborator of agents and AI capabilities rather than competing to become the agent for the enterprise.

2. Agentforce Voice

Agentforce Voice extends the power of the Agentforce platform by allowing agents to talk, bringing AI capabilities directly to contact centers and 800 numbers. Businesses can now configure the voice, tone, and personality of the AI right inside the AgentForce Builder. The goal is to deliver a unified customer experience across all channels, providing a highly human-like and interruptible conversational flow. A critical feature of Agentforce Voice is ensuring a seamless transition when the AI needs to transfer a customer to a human agent; the human representative automatically receives the full transcript and context of the AI conversation, allowing them to pick up the experience precisely where the AI left off. This functionality is available GA October ’25.

3. Intelligent Context Processing (Data 360)

Intelligent Context Processing tackles one of the greatest challenges for AI agents: understanding and utilizing vast amounts of complex, unstructured data. Agents often struggle with content in rich formats, pictures, tables, and existing workflows, the accumulated wisdom of the company. These new tools, built into Data 360, interpret and index this data by analyzing and parsing complex content (such as product manuals containing charts and images). This allows agents to pull in the exact, correct context required to deliver accurate and rich responses at the precise moment it is needed.

Furthermore, Data 360 enhances governance across both structured and unstructured data. Using natural language, administrators can create policies, such as masking internal FedEx employee contact details within agent responses, ensuring the information provided is not only accurate but also appropriate for the customer. It is not clear to us whether this is solely a rename of the product called Data Cloud. It seems that way.

4. Agentforce Vibes

Salesforce launched Agentforce Vibes as a new product that lets trailblazers quickly and easily build apps, dashboards, automations, and flows. Users achieve this via vie coding, which involves providing a simple, natural language description of what they want the platform to build. The core innovation of Agentforce Vibes is its deep contextual understanding; it speaks “the language of the business,” including the organization’s data, relationships, customers, products, and security permissions. This contextual intelligence allows Agentforce Vibes to rapidly translate a descriptive idea into deployable, production-grade Salesforce metadata (such as a screen flow). This drastically reduces development time, saving what could amount to dozens of manual clicks inside a traditional flow builder. This effectively elevates the capabilities of every developer. Interesting tidbits: Developers can develop using the coding language of their choice, and there is a local LWC preview function that will be launched soon.

5. Slackbot

Salesforce unveiled Slackbot as a new personalized, AI-powered companion that boosts productivity directly within Slack. It will launch for General Availability (GA) in January and draws on each user’s unique organizational context, including conversations, files, workflows, and apps. The tool moves users beyond asking simple questions toward achieving complex, tangible outcomes. For example, a user can ask Slackbot to handle a multi-step process with one command. It can review deal status, find compliance files, and draft a customer email in the user’s tone. Slackbot can also create a prep document and calendar invite for key stakeholders automatically. Slackbot will be the home of AI capabilities within Slack, even for customers who don’t use Salesforce.

6. Support for Third-Party Agents in Slack (AgentExchange)

Salesforce affirmed its vision of Slack becoming the “home for all AI” by announcing support for all third-party AI agents, such as ChatGPT, Claude and Gemini. This transformation positions Slack as an agentic operating system where external agents can exist as collaborative “teammates” alongside human employees. To ensure these external agents can perform sophisticated reasoning, they are grounded in the company’s real-time knowledge and context via a real-time search API and an MCP server. This initiative allows Salesforce agents to work in conjunction with agents from other platforms. This coupled with the AI-assisted enterprise search capabilities of Slack empowers Slack admins and users to be more productive.

7. Agentforce Observability

Agentforce Observability was introduced to help monitor and scale digital work in the new agentic enterprise era. It serves as one control center for managers to monitor and improve agent team performance. The tool gives leaders visibility into KPIs like escalation and deflection rates using Tableau Next analytics.

Most importantly, it features Agent Insights, which acts as a performance review by scoring every single agent session. This scoring helps managers find and analyze poor-performing conversations to uncover root causes like process issues. It enables tuning of agent prompts and behaviors for consistent results. This management layer is essential since prompts and loops alone aren’t enough.

This was a major pain point with the clients. I am happy Salesforce is addressing it with this new functionality that will be available for most clients.

Conclusion

I personally found the announcements more evolutionary than revolutionary. It was not a strong Dreamforce in terms of new functionalities covered.

Adoption challenges and cleanup are still needed to make current products appealing. These announcements mark real progress for Salesforce.

[youtube https://www.youtube.com/watch?v=_S18LAXcBYQ?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]

Explore related content:

Salesforce Ushers in the Age of the Agentic Enterprise at Dreamforce 2025

Dreamforce 2025: Standout Sessions Streaming on Salesforce+

Salesforce Winter ’26 Release: Comprehensive Overview of New Flow Features

Tired of downloading Salesforce files one by one? 😫
Watch how our Files Downloader App lets you download all your Salesforce files and attachments — in bulk and in seconds ⚡

👉 Try Files Downloader for Salesforce: appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000HEWTBUA5

#filesdownloader #salesforceapps #salesforcecrm #exportfilesfromsalesforce #massexportsalesforcefiles #accountrecord #downloadsalesforcefiles #dataloader #salesforcehunt #salesforcedevelopers

How to Quickly Build a Salesforce-Native Satisfaction Survey Using SurveyVista

SurveyVista by Ardira is a Salesforce native survey solution that allows you to design, distribute, and analyze surveys directly within your Salesforce org. Unlike external survey tools that require complex integrations or third-party data syncs, SurveyVista keeps everything in-platform. This gives admins and business users a secure, streamlined way to capture feedback without leaving Salesforce.

Why Salesforce-Native Matters

Many survey tools rely on connectors, middleware, or APIs to bring data back into Salesforce. While this approach works, it introduces several challenges. Data leaving Salesforce and traveling across external systems creates additional security risks. It also increases integration overhead by requiring ongoing maintenance, troubleshooting, and vendor updates. On top of that, responses may not be available in real time inside Salesforce, which can slow down reporting and automation.

SurveyVista avoids these issues because it is 100% Salesforce native. Data never leaves your org and remains protected under the Salesforce trust framework, giving you stronger security. Responses are available instantly, making them immediately usable for reporting, flows, and automation. Since no external integration is required, admin overhead is reduced and your tech stack stays simple.

SurveyVista Install and Preparation

SurveyVista is an AppExchange solution. You can head over to the AppExchange and install the free/trial version of SurveyVista in your Org. Get it HERE.

Once you install the AppExchange package you can go to the lightning page and finish up your configuration there. The required steps are fairly simple and they relate to publishing a digital experience site where the surveys will be hosted. There are a few steps that require you to copy and paste code into the Developer Console and execute them. You should also check on the digital experience builder whether your digital experience site requires login or not. If you are going to host the survey publicly and accept anonymous responses, then your digital experience site needs to be made public.

You will also find on this page an option to download templates and examples. I find the template that includes all UI components very useful, because it quickly shows you what is possible.

You can start your survey from scratch or from a template.

Build

I decided to build a 5-question CSAT and NPS form. One question will accept the NPS score, while the last question will accept free-form text for open feedback.

The form structure is as follows:

Customer Satisfaction Survey

Q1. How satisfied are you with your overall experience?
Very satisfied / Satisfied / Neutral / Dissatisfied / Very dissatisfied
Q2. How would you rate the quality of our product/service?
Excellent / Good / Fair / Poor
Q3. How likely are you to recommend us to a friend or colleague?
NPS scale (0-10)

Q4. How responsive have we been to your questions or concerns?
Extremely responsive / Very responsive / Somewhat responsive / Not so responsive / Not at all responsive

Q5. Please share any additional feedback or suggestions you may have.
Paragraph (free-form text)

SurveyVista offers ready components for you to add these inputs on your form. The customization options seem virtually limitless. Branding your survey is easy.

You can also customize your “Thank You” landing page and provide links on that page, as well.

Once you complete your design, you add the digital experience site to your survey and publish it. SurveyVista produces two links for your Survey form. One can be used for internal users, the other one for external users. You can send this link to your audience anytime on any channel, either manually or automatically.

Result

Here is the resulting form.

The beauty of SurveyVista is that the response is recorded in your Salesforce Org as an object record. You can trigger automation when the record is created, and relate this record to any record(s) you want in your Salesforce Org.

You can use the reports and dashboards SurveyVista package gives you, or set up your own reports and dashboards in Salesforce. In addition to relating to records, you can use response mapping features to automate creating and/or updating Salesforce standard or custom object records.

Overview of SurveyVista Features and Use Cases

SurveyVista includes a survey builder that lives entirely in Salesforce, allowing you to create surveys with customizable questions, logic, and branding. Responses are stored directly in Salesforce records through a native data model, eliminating the need for external syncs or integrations.
Because the tool is built on Salesforce, responses can trigger Flows, Approvals, or Processes automatically. You can also analyze results using standard Salesforce Reports and Dashboards, and distribute surveys securely through Salesforce email, Experience Cloud, or custom links.

One important note is that SurveyVista can handle both authenticated and unauthenticated respondents. If you want to collect responses from external participants who do not have a Salesforce login, you can do so through public or personalized links. For authenticated external respondents, such as community users who log in through a Salesforce Digital Experience site, additional Salesforce licensing may be required.

Use Cases:

• Customer Satisfaction (CSAT) and NPS: Gather customer insights after key interactions.
• Employee Feedback: Collect internal survey responses securely.
• Training Assessments: Get immediate feedback from attendees.
• Operational checklists: Inspection checklists guiding the inspector to complete a list of tasks.
• Custom Business Processes: Build forms and capture input tied directly to Salesforce records.

Why Choose SurveyVista?

If your team values security, speed, and simplicity, SurveyVista gives you a native first alternative to tools like Qualtrics or SurveyMonkey. Because everything lives in Salesforce, you avoid integration headaches and keep sensitive data where it belongs, under your org’s security umbrella.

SurveyVista keeps all survey responses inside Salesforce, giving you real time insights that combine feedback data with your existing customer CRM data, so you can take immediate action without waiting on integrations or external syncs.

SurveyVista Pricing: What It Costs and What You Get

SurveyVista is priced on an annual, org-wide basis, with plans starting at US $2,999 per year for smaller organizations. This gives you full access to a Salesforce-native survey solution without the overhead of integrating an external system.

There is also a Free Edition that includes core survey builder functionality. The free version comes with certain limitations, such as restrictions on how respondents access the survey, but it is a good way to explore the product and test it out inside your Salesforce environment.

Paid tiers begin at around $2,999 per year and scale up depending on your organization’s size and requirements. Larger organizations or those needing more advanced features can expect higher-tier plans in the range of $5,499 per year or more. For enterprise needs, Ardira offers custom pricing tailored to the scope of your surveys and the scale of your Salesforce org.

SurveyVista also supports a free trial of its paid tiers, so you can evaluate the tool before committing. See more pricing details on their website HERE.

Conclusion

SurveyVista makes collecting and acting on feedback simple, secure, and Salesforce native. Whether you’re measuring customer satisfaction, running employee surveys, or embedding forms into business processes, everything stays inside your org, where it’s accessible in real time, protected by Salesforce security, and ready to power automation. With flexible pricing, a free edition to get started, and an intuitive builder that lives in Salesforce, SurveyVista is an accessible solution for any team that wants actionable insights without integration headaches. Try it today at the Ardira website to see how easily you can bring surveys into Salesforce!

This post was sponsored by SurveyVista by Ardira.

#Adrira #AppExchange #SaleforceTutorials #Salesforce #SalesforceAdmins #SalesforceDevelopers #SurveyVista