Our forward-looking statement applies to roadmap projections.

Roadmap corresponds to June 2025 projections.

Guide Overview

Looking to build forms on the Salesforce Platform? You’ve got multiple options, spanning the entire low-code to pro-code continuum. Representing low-code are Dynamic Forms in Lightning App Builder and screen flows in Flow Builder. Hanging out in the middle of the continuum is the ability to extend screen flows with LWCs and building customer-facing forms with OmniStudio. And representing pro-code is the LWC framework and its ever-growing library of base components.

Options are great, but how do you determine which one (or which combination) is the right option? That’s where this guide comes in.

This guide focuses on form-building options for working with records in Salesforce. You’ll see a similar assessment, focused on orchestrating automation logic within Salesforce in the Architect’s Guide to Building Record-Triggered Automation on Salesforce.

Key Takeaways

Keep in mind, your choice doesn’t have to be an either/or - you can combine the power of multiple options. For example, if you need both Flow’s built-in navigation system and the full styling flexibility that LWC offers, use them together.

Tools for Building Forms with Salesforce

The table below outlines the tools that are available for building forms with Salesforce, along with their required skills and license considerations. Later we’ll dive deeper into the specific features that are supported for each tool, as well as how to choose between click-based tools and code-based tools (and when to combine them):

Skills Required Additional License Requirements
Dynamic Forms Low Code No
Screen Flow Low Code No
OmniStudio Low Code + Pro Code Requires Industries Package
Screen Flow + Lightning Web Components Low Code + Pro Code No
Lightning Web Components Pro Code No

Decision Points At-a-Glance

The table below contains an overview of the decision points that you'll want to think about when making your product selections, along with questions you should be asking yourself about each one. We'll be diving deeper into each of these topics throughout the rest of this guide.

Object Impact Determine whether your form will operate against a single object or needs to operate against multiple objects.
Form Scope and Navigation Determine whether all of the fields on your form will fit logically onto a single screen, or if users should be able to navigate between multiple screens.
Location Identify the location(s) where you want to embed the form, which can range from somewhere within a Salesforce app to a mobile app or even an external website.
Controller Identify the actions or logic that need to be performed behind the scenes while users are interacting with your form, including data transformations and integrations with external systems.
Validation Determine whether or not you have any additional input validation requirements that go beyond the standard system level validation provided by Salesforce.
Security Determine whether your form should check the user’s access before performing certain operations, whether you want to control who can access the form and whether you want to control where the form can be embedded.
Interaction Design Identify the types of interactions or conditions that should trigger dynamic responses within your form.
Styling Determine the level of sophistication for your desired styling and CSS.
Layout Identify your form's layout requirements in terms of the required number of columns, tabs, accordions and the ability to display repeating blocks of data.
Translation Determine whether your form will need to be localized to other languages.
UI Test Automation Determine whether your DevOps processes will require your form to undergo automated unit testing or automated end-to-end testing
Metrics Identify the ways you'd like to track your form's usage, including page views, amount of time spent on the form, completion rates and success rates
Packaging and Deployment Determine how you want to distribute or deploy your form after it's been built.

Below are the terms we use in the comparison tables along with their definitions:

Decision Point Walkthroughs

As promised, let’s start a deep dive into a variety of comparison points and functional differences between Dynamic Forms, Screen Flows, OmniStudio, Screen Flows with embedded LWCs, and the LWC framework itself.

Object Impact

If your form operates against a single Salesforce object, any of the tools we’re comparing will work. Things get a little more complicated with cross-object or object-agnostic forms. By object-agnostic, we mean inputs that don’t map to any Salesforce object. Perhaps your form represents a data structure that you’ll send to an external service, like Stripe or DocuSign. Or perhaps you’re using several inputs in your form to calculate a value, and then committing that value to the database.

Questions to ask:

Single Object Cross-Object Object Agnostic
Dynamic Forms Available Available Not Available
Screen Flow Available Available Available
OmniStudio Available Available Available
Screen Flow + LWC Available Available Available
LWC Available Available Available

For both cross-object and object-agnostic forms, Flow and OmniStudio are both solid options. The components available in flow screens are agnostic by nature, so you can choose what to do with that data behind the scenes. For example, use the data entered in one form to create multiple records behind the scenes, or use the data to perform other actions like generating Chatter posts, sending Slack messages, sending emails, or connecting to external services.

For simple cases, using existing LWC components, like lightning-record-form, can be a simple way to lower code needed to provide a robust solution. However, for scenarios where multiple objects are involved, Flow provides comprehensive control for all objects and removes the need for developers to traverse complex relationships and dependencies.

OmniStudio takes things a step further and is completely object agnostic — it separates the form a user sees from the underlying data model. Instead, OmniStudio manipulates underlying JSON that then is mapped to Salesforce objects (or external data) using tools like Data Mapper and Integration Procedures. Data Mapper and Integration Procedures are two key components in connecting your OmniStudio forms with data internal and external to Salesforce. Using drag-and-drop elements, you can work with complex hierarchical data in an external system and then transform the data to fit your needs depending on where the data needs to go. They also allow you to use formulas to perform math and logic on arrays, or lists of data, much like Apex.

OmniStudio IntegrationsOmniStudio Integrations

Form Scope and Navigation

If you can get all of your user inputs from a single-screen form, start with Dynamic Forms. However, while Dynamic Forms in Record Pages can use the Path feature to loosely represent the various stages in your business process, it may not fit the majority of your use cases.

Questions to ask:

Single Screen Multi-Screen Form Progress Indicators Jump Navigation Between Steps / Screens
Dynamic Forms Available Not Available Available Not Available
Screen Flow Available Available Roadmap Roadmap
OmniStudio Available Available Available Available
Screen Flow + LWC Available Available Available Available
LWC Available Not Ideal Not Ideal Not Ideal

If you need more functionality than what Dynamic Forms offers, the choice between Flow, OmniStudio, and LWC will depend on a few other questions as well:

If, on the other hand, your solution looks like a wizard, where the user navigates between multiple screens, consider Flow or OmniStudio. Flows and OmniStudio come with a built-in navigation model, so you don’t have to build and maintain LWCs that are strung together. The navigation is linear in nature, with forward-moving actions, backward-moving actions, and a mechanism for saving the form for later. You can also build a form with non-linear navigation if it suits your purposes. For a great example of that using screen flows, check out the Digital Store Audit package from Salesforce Labs.

OmniStudio offers a key navigational advantage by providing progress indicators from standard navigation that surfaces ‘steps’ in the form. This step view automatically displays where a user is on a given multi-step form. Unlike Flow, it lets users ‘jump’ between screens by clicking on various steps of the form.

Roadmap Note: In Spring '25 Screen Flows will have the ability to add a progress indicator to a screen without code.

Regardless of whether you’re building single screen or multi-screen forms, make sure that your forms are streamlined so that they’re easy for your users to navigate.

Location

If you’re embedding a form in a standard Lightning Record Page, any of the tools we’re comparing will work, with the caveat that Dynamic Forms are currently only available on the desktop. However, if you’re looking to provide an experience that allows users to access forms from other locations, you may need to consider alternate options.

Questions to ask:

Lightning Record Page Lightning Home Page or App Page Aura Experience Sites LWR Experience Sites Embedded Snap-Ins Utility Bar Object-Specific Action Global Action Salesforce Mobile App** Field Service Mobile Mobile SDK External Sites and Apps Custom LWC
Dynamic Forms Available Not Available Not Available Not Available Not Available Not Available Not Available Not Available Available Not Available Not Available Not Available Not Available
Screen Flow Available Available Available Available Available Available Available Roadmap Available Available*** Not Available Roadmap Available
OmniStudio Available Available Available Not Available Not Available Available Not Available Not Available Available Not Available Not Available Available Available
Screen Flow + LWC Available Available Available Available Available Available Available Roadmap Available Not Available Not Available Not Ideal Available
LWC Available Available Available Available Available Available Roadmap Roadmap Available Roadmap Roadmap Available Available
*Flows can be embedded in LWR Experience Sites but do have considerations you need to keep in mind.
****Flows and LWCs are supported in the Salesforce mobile app, but the Salesforce mobile app doesn’t support all the ways you can embed flows and LWCs. For example, object-specific actions are supported in mobile, but utility bar items are not.
***The Field Service Mobile app does not support many of the latest Flow features as it is designed from an older Flow Engine and Screen Flow Runtime - it has special modifications for it to work offline.

Since they require record context, Dynamic Forms are supported only in Lightning Record pages. However, Dynamic Forms aren’t supported in Experience Cloud pages. This limitation is in place because Experience Cloud doesn't use the underlying framework that Dynamic Forms depends on: Lightning Pages. We are evaluating this as based on requests for Dynamic Forms in Experience Cloud.

You can build flows that require a record context or flows that work globally. As such, you can embed flows in a variety of locations. For record-contextual flows, that might be a Lightning record page, an Experience Cloud record page, an object-specific action, or an Actions & Recommendations deployment. For the global flow, that might be the utility bar, other Lightning or Experience Builder pages, a snap-in, or an external application. Flows are not currently supported as global actions, but as a workaround you can wrap the flow in an Aura component.

OmniStudio lets you build composable FlexCards and Omniscripts that you can place almost anywhere you can put a Flow. However, while composable, they are not packageable.

LWC supports a high degree of reusability, since you are creating components that can be associated with targets via metadata across Salesforce, Communities, and even in open-source projects. LWC components can also be embedded inside of your own website via Lightning Out.

Roadmap Note: Aura-based Lightning Out will be generally available in Winter '25

Lightning Out on External SitesLightning Out on External Sites

Lightning Web Components aren’t currently supported as quick actions (object-specific or global), but as a workaround you can wrap an LWC in an Aura component (much like you can with flows). LWC components can also launch flows with the lightning-flow component.

OmniStudio excels at exposing content to your external sites through the OmniOut feature. With OmniStudio and OmniOut, you can compile your Omniscript forms and FlexCard components into standard components and run them off-platform in third-party sites or apps.

None of the form technologies covered in this guide are officially supported in Mobile SDK templates today. If Mobile SDK is essential to your use case, you’re better off building your form natively in your mobile application or building a Visualforce page, while keeping Salesforce Well-Architected form factor guidance in mind.

Roadmap Note: The Mobile SDK team is actively working on supporting LWCs within Visualforce pages.

Controller

Dynamic Forms are perfect if you need to use the values in your form to create or update a record. For any capabilities beyond that, you’ll need to leverage Flow, OmniStudio, or LWC. Those capabilities might include a layer of decisioning or iteration, or the generation of Slack posts or emails using the inputs from the form.

Questions to ask:

Log & Actions Hierarchical Data Management Operate within One Transaction Operate Across Multiple Transactions Integration Modular Design & Reuse Packaging
Dynamic Forms Not Available Not Available Not Available Not Available Not Available Not Available Available
Screen Flow Available Roadmap Available Available Available Available Available
OmniStudio Available Available Available Available Available Available Not Available
Screen Flow + LWC Available Available Available Available Available Available Available
LWC Available Available Available Available Available Available Available

Flow offers standard actions for posting to Slack, sending email, and interacting with Quip documents, so you don’t have to write code for these operations. LWC offers rich interactions with single records and related objects through the use of wire adapters that interact with User Interface API. LWC can also interact with multiple records when using the wire for getListInfoByName.

LWC Interaction via Wire AdaptersLightning Web Components Interaction via Wire Adapters

As mentioned above, OmniStudio uses Integration Procedures and Data Mapper to easily grab and transform data external and internal to Salesforce. It shines in flattening and expanding data sets with various levels of relationships thanks to numerous code-free functions you can use.

Roadmap Note: Flow will soon support the ability to upsert collections of records, as well as manage hierarchical data.

Flow, OmniStudio, and LWC all integrate with Apex, so you can easily close any gaps in whichever solution you choose. For example, if you require filtering records from an LWC you can always use the wire adapter for Apex to create complex SOQL queries. If you’re swayed by the click-based story, consider Flow or OmniStudio as viable alternatives to an Apex controller for your server-side needs.

A secondary question here is whether you want to immediately commit actions, or defer them to a particular part of your form. This is especially relevant if you’re in a multi-page form. Flow makes it easy to combine inputs from multiple forms (flow screens) and use them much later in the wizard (flow) to perform some operations. In fact, we recommend designing flows in just that way — perform actions at the end — in case the user bounces back and forth between screens, changing their answers.

Controlling Operations

Transactions and governor limits are a way of life on the Salesforce Platform. If your use case is fairly simple, it may not be as important to control what transaction a particular operation occurs in. However, there are a few use cases where you might want to combine multiple operations into a single transaction rather than performing them across multiple transactions. Some examples:

When you use a Dynamic Form to create or edit a record, you’re only ever performing one operation, and that operation is always the start of a net-new transaction.

When building a screen flow, you have significant control over what happens in a given transaction. Screens and Local Actions act as boundaries between transactions. Here’s a high-level summary of how transactions are managed in the screen flow architecture.

  1. The end user interacts with a screen, and then clicks Next.
  2. The client posts a request to the API with the inputs.
  3. The API receives the request, and a transaction and database connection are opened. The API then calls the Flow engine to invoke the request.
  4. The Flow engine takes over and follows the appropriate path in the flow definition — until it hits a Screen or Local Action node. The engine then returns information about that node to the API.
  5. The API creates a response object that contains the details of the next screen to render, and returns that object to the client. At this point, database changes are committed (cue the save order execution), and the database connection and transaction are closed.
  6. The client uses the API response to render the next screen for the user to interact with.
  7. Repeat from step 1.

In other words, screens “break” transactions. When that happens, any pending actions or DML are committed, the prior transaction is closed, and a new transaction starts.

multi-screen flow

The right design — which operations you group into a given transaction — is your call. Let's walk through some examples.

screen flow with separate transactions

On the left, you can see a flow that collects inputs across multiple screens, and then performs several actions in one transaction.



The flow on the right performs each operation in a separate transaction.


The Flow team recently introduced a new element: Roll Back Records. This element enables you to roll back an entire transaction if a single operation fails in a series of database operations.

Screen Flow with multiple create records

Suppose you have a Flow that creates records, updates records, then creates more records — as illustrated in the next flow on the right.

In this scenario, if the first two elements succeed and the last fails, the first two DML operations will still create and update those records while the third will not.


Screen Flow with Rollback

By using the Roll Back Records element, you can ensure the entire transaction is rolled back if all three operations have to occur in tandem — as seen in the final flow on the left.


For more details, check out Flows in Transactions and Flow Bulkification in Transactions. The Automated section of Salesforce Well-Architected also goes into more depth about this in Data Handling.


Your ability to control the transaction from an LWC comes down to the underlying services that LWC is using to perform its operations. If you’re using the lightning-record-form base component, the underlying operation (creating or updating the record) happens in a standalone transaction as soon as the form is submitted.

In general, these rules apply:

External Integrations

Flow, OmniStudio, and LWC all support platform event (for event-driven architecture) and API integrations. In addition to custom Apex code, both Flow and OmniStudio support declaratively mechanisms to integrate an API.

If you need to connect to a Mulesoft API or RPA bot, use Mulesoft Services. This generates an External Service.

External integrations via MulesoftExternal Integrations via Mulesoft APIs and RPA Bots

If the API has an OpenAPI schema, create an External Service.

External Integrations via OpenAPIExternal Integrations to APIs with OpenAPI Schemas

Otherwise, use the HTTP Callout feature in Flow or HTTP Action in OmniStudio. Flow’s HTTP Callout is powered by External Services.

External integrations via HTTPExternal Integrations via HTTP

OmniStudio features a rich set of integration capabilities that can call out to external systems with Integration Procedures and transform the data with Data Mapper. (See Object Impact for more information)

Regardless of whether you implement it with custom Apex or an external service, a callout is a callout. Here’s what you need to know.

  1. A callout can take a long time.
  2. When a callout is executed synchronously, it's performed while a database transaction is open.
  3. Salesforce doesn't let you keep a database transaction open if you have pending database operations.

The main limitation to keep in mind is the danger of so-called dirty transaction, where you perform a create, update, or delete operation and then, in the same transaction, execute a callout. This pattern isn’t allowed because of consideration #3 above, which of course exists because of considerations #1 and #2.

In Flow, you can work around this limitation by breaking the transaction. Remember that screens and local actions both reintroduce the browser context, which breaks the transaction. Although you could use screens and local actions when working with external callouts, we recommend enabling Transaction Control in invocable advanced settings. Transaction Control is a feature of invocable actions that lets you automatically end the transaction before a callout is made. You can enable Transaction Control by selecting Always Start a New Transaction in the Advanced section of an invoked action.

External Integrations via Callouts

The impact of callouts on the transaction is less complicated with LWC. Generally speaking, you’ll perform your data operations using the Lightning Data Service (LDS), and then use an Apex controller to make the external callout. This design protects you from dirty transactions, since the LDS call is isolated in its own transaction separate from the Apex callout.

For more in-depth guidance about Apex Callouts, External Services and data integration capabilities in general, see the Architect's Guide to Data Integration with Salesforce.

Reusability and Modularity

Dynamic Forms doesn’t support reuse. Each Dynamic Form is tied to a specific Lightning record page for a specific object (though you can assign that Lightning record page to multiple apps, profiles, and so on).

Much like you can write libraries, utilities, and components that are intended to be used across multiple other components, you can apply similar design patterns when creating flows with the power of subflows. Save your flows in smaller, more modular buckets, and then call them from other flows by using the Subflow element. If your design calls for it, you can build a flow that both stands on its own and is useful as a subflow of another one.

OmniStudio is inherently built for modularity. Data Mappers, Omniscripts, FlexCards, and Integration Procedures are all built independently, and can work interchangeably. On top of that, FlexCards can be built as LWC components that are embeddable in other LWCs, Omniscripts, record pages, and Experience Sites.

Screen flows, Omniscripts, and LWCs can all be built for reuse and embedded in a variety of locations including external sites and Lightning Out applications. When you design your solutions to be composable you get additional benefits like adaptability and stability.

Validation

All technologies that are used to create or update a record adhere to system-level validation – whether those are classic validation rules or custom validation built into an Apex trigger. No matter what technology you use to perform a record change, every change goes through the save order. That means in addition to validation rules, the record change is processed by any number of before- or after-save flows, before or after triggers, escalation rules, assignment rules, and more. If you haven’t already, be sure to bookmark and familiarize yourself with the Apex order of execution.

Questions to ask:

Respect System-Level Validation Custom Field-Level Validation Specific to this Form Custom Field-Level Validation
Dynamic Forms Available Not Available Not Available
Screen Flow Available Not Available Roadmap
OmniStudio Available Available Available
Screen Flow + LWC Available Available Available
LWC Available Available Available

Inputs on a flow screen or Omniscript step are by nature unbound, so the form itself doesn’t natively adhere to system-level validation associated with a particular object. Whatever values you use to create or update records, however, are processed by the save order, which means they pass through the object’s system-level validation. Note, though, that not all screen flow components support input validation. As of Summer '24, the remaining screen components that don't support input validation are Radio Buttons, Picklist, Multi-Select Picklist, Checkbox Group, and Choice Lookup.

Just like page layouts, Dynamic Forms let you set requiredness and read-only state at the page level. However, you can’t override system-level settings.

Flow provides flexibility for customizing validation on a form’s inputs. While some checks are performed in the client (like flagging missing required fields or incompatible values), none of the client-side validation blocks the user from trying to navigate. The real validation happens on the server. When a user clicks Next, Flow sends the inputs to the server for validation. If any inputs are returned as invalid, navigation is blocked and the appropriate error is displayed. The server validates the inputs by checking:

  1. The input’s requiredness setting, or whether the entered value is compatible with the underlying data type.
  2. Custom validation on that input: Several standard components (Checkbox, Currency, Date, Date/Time, Long Text Area, Number, Password, and Text) support custom validation on a per-screen basis. Supply a Boolean formula expression and an error message to display when the formula expression isn’t met.
  3. Custom validation on the underlying component: If you’re building a custom LWC for a flow, add your own validation code to the validate() method.

Roadmap Note: In Winter '24 input validation for screen flows will evaluate in real-time, rather than only when the user navigates forward.

OmniStudio features rich error and validation handling via the Set Error action in combination with Conditional Views and the Messaging component.

On the LWC side, most base components perform their own client-side validations. For example, lightning-record-form respects system-level requiredness, but not page-level requiredness. For your custom components, you can build your own validation mechanisms.

Fields that require users to input data should appear early in your forms. Whenever possible, validate user inputs on the client side before forms are submitted. For more best practices on streamlining your forms, see the forms guidance in Salesforce Well-Architected - Engaging.

Security

Security is a complex topic in general, and when it comes to building forms, there are a number of considerations that you might not have even thought about. At the foundational level, you’ll want to make sure that the form is running in the correct context and that users have the permissions they need to work with its underlying data. But beyond that, you may also want to take extra measures to strip out potentially malicious code or URLs from rich text fields, prevent certain users from being able to access the form at all or put limitations on the types of places where admins can potentially embed the form in the future. Make sure to document your security requirements thoroughly before choosing a tool. The Salesforce Well-Architected Security Policy Template contains guidelines for this type of documentation.

Questions to ask:

Elevate User Permissions Control Who Has Access Restrict Allowed Locations
Dynamic Forms Not Available Available Not Available
Screen Flow Available Available Not Available
OmniStudio Not Available Available Not Available**
Screen Flow + LWC Available Available Not Available
LWC Available* Available Available
*Requires Apex
**While Omniscripts cannot have a specified set of target locations, FlexCards can.

Elevating User Permissions

When something runs in user context, Salesforce enforces a series of access checks, including verifying field-level security, CRUD permissions and record access based on your org’s sharing rules. So for example, users would only be able to run a case update form if they have the ability to update cases, the appropriate field-level security, and access to the record in question. But what if you want users to be able to perform a particular operation when they're using your form, but not through any other form or interaction? That’s where system context comes in.

System context is a way to elevate the running user’s permissions for the duration of the session, so that the user doesn’t need, for example, Update access to the Case object to successfully complete your case update form. This is especially useful for unauthenticated communities. Instead of granting guest users potentially dangerous abilities, set your form to run in system context.

Of course, system context is a double-edged sword and you should use it only when necessary. When a form runs in system context, every single CRUD operation bypasses object- and field-level security and sharing — not just the specific operation you care about. Also note that system context has no bearing on who Salesforce considers the actor – the name you see in the Last Modified By field. For each operation that your form performs, such as the case update, the actor is the running user even if the form runs in a different context.

Dynamic Forms, Omniscripts, and LWCs always run in user context, and there’s no way to override this behavior.

Screen flows run in user context by default, but you can set them to run in system context. It’s your choice whether the flow should grant access to all data or if it should still enforce record-level access like sharing.

Querying for Records in System Context with Experience Sites:

If you are running a flow in system context on an Experience site, especially unauthenticated, we recommend storing only specific fields in your Get Records elements. When you're working with Flow and you pass the results of a Get Records element into a subflow, invocable action, or a Lightning component, all fields from that object can be inspected via the browser’s developer tools. This might make fields available to your Experience site users you may not intend. By specifying specific fields in your Get Records elements, you can ensure only the right fields are exposed even with system context enabled.

Note that Omniscript logic runs on the client side, which makes it possible for attackers to modify the expected execution of an Omniscript and view responses to Integration Procedures, Data Mappers, and Apex method calls using the browser's developer tools. When you're using Omniscript, we recommend executing business logic on the server side whenever possible and implementing input validation rules on any Apex methods that are exposed via an @InvocableMethod annotation.

Sanitizing Inputs:

To protect your org from bad actors, also consider input sanitization. Suppose you have an input on a publicly accessible form that could be mapped to a Rich Text field in your org. You may want to consider automation that strips out any HTML that could hide malicious URLs. In general, it’s not ideal to implement this sanitization at the form level, because you could have any number of sources write to these fields. We recommend creating a Fast Field Update Flow (Before Save) or use an existing Apex Trigger on the object to strip out or modify any potential HTML that might be entered in the form.

Best practices:

  • Leave Flows to run in their default context unless you need to elevate the running user’s access for a specific operation.
  • Avoid running Flows in system context for guest users for security reasons. Create permission sets with limited field access assigned to the Experience site’s guest user profile instead.
  • When querying for records in system context-run Flows on experience sites, only store the fields you need in your Get Records element or Invocable Actions.
  • If a Flow performs a variety of operations and not all of them require elevated access, use subflows to isolate the operations that should run in system context.
  • If you plan to embed a form in an external webpage, consider sanitizing user inputs to remove HTML using a Fast Field Update Flow or Apex Trigger if they will eventually be mapped to Rich Text fields to prevent any potential phishing attacks from bad actors.

Additional Notes:

Access Control

If you need control over who can access your form, you can often look to the container in which the form is embedded. For example, you can assign Lightning pages to be available for particular apps, record types, or profiles. If certain inputs in your form are sensitive, use visibility rules to further control what is displayed to whom; this feature applies to both Dynamic Forms and screen flows.

You can restrict a flow to particular profiles or permission sets, much like you can an Apex class or Visualforce page. By default, flows are unrestricted, which means that any user with the Run Flows user permission can run them.

If you're using OmniStudio, you can configure an Apex class permissions checker to ensure that users require explicit access to the Apex class that administers the remote action called from an Omniscript, Flexcard, Classic Card, or REST API.

For more details and best practices on guest user permissions see:

Best Practices:

  • If you’re exposing a flow to guest users, grant the guest user profile access to only the flows they need. Although it is possible to add Run Flows to the guest user profile, we consider that a risky practice.
  • Be especially careful with flows that operate in system context. We strongly recommend you restrict those flows to a particular set of users, since they have fewer checks and balances in place to protect your data.
  • Ensure that any Omniscript that runs Apex in a guest user community has "with sharing" in the Apex class definition.
  • On your Guest User profile, assign only those Apex classes that you want guest users to be able to call or you risk unintentionally exposing additional business logic to guest users.

For LWCs, you can check the running user’s permission assignments to confirm if they have a particular standard or custom permission. Directly from JavaScript, you can import Salesforce permissions from the @salesforce/userPermission and @salesforce/customPermission scoped modules. Or you can use Apex to check the same.

Embedding Control

Lightning Web Components are available in a given location only when it’s been added as a valid target. For example, you can make a component available on Record pages and not available as a utility bar item.

Once a screen flow is activated, it’s available in all the locations that screen flows are supported, regardless of whether you intended it to be available everywhere or not. That said, Flow Builder supports multiple types of flows that have screens. The bread-and-butter type is Screen Flow, but there are a few other specialized types that are restricted to specific locations. For example, the Field Service Mobile App only supports - you guessed it - Field Service Mobile Flows. The same goes for Contact Request Flows, which are supported only in Experience Cloud.

Regardless of the flow type, the individual making the flow has no control over where the flow can be embedded. The flow will be available in every location supported for that flow type.

If you’re using Salesforce Industries, there’s a slight caveat when it comes to Omniscript: While you can’t specify a target for an Omniscript itself, you can specify one for the FlexCards that you may want to embed into it.

Interaction Design

Static forms are a thing of the past. Today, it’s all about dynamically updating the form with the right properties and values for this user, this time, this place. Let’s talk about what’s possible in this vein for Salesforce’s form-building tools.

Questions to ask:

Execute Off-Screen Data Operations Conditional Values & Calculations Conditional Visibility Conditional Requiredness Conditional Formatting Conditional Read-Only State Conditional Disabled State
Dynamic Forms Not Available Not Available Available Not Available Roadmap Not Available Not Available
Screen Flow Available Available** Available Available* Not Available Available** Available**
OmniStudio Available Available Available Available Available Available Available
Screen Flow + LWC Available Available Available Available Available Available Available
LWC Available Available Available Available Available Available Available
**Limited to components that use a resource picker and not a static checkbox
**Limited Beta

Screen Flow interactivity is now a reality thanks to the Reactive Screens effort that is generally available as of Winter ‘24. Reactivity allows individual components on a flow screen to communicate with each other - making screen flows infinitely more powerful.

Execute Off-screen Data Operations: Screen Flows offer a declarative approach to fetching data on the same screen through Screen Actions, a feature that is available as a Beta in Summer ’24.

LWC offers a full array of wire adapters that let you access Salesforce data to populate data in your form’s components dynamically, and enables developers to update, delete, and create records through Apex controllers.

Lightning Web Components Off-Screen Data OperationsLightning Web Components Off-Screen Data Operations

Visibility: Visibility can be dynamically controlled in all form building tools. Dynamic Forms, Flow Builder, and OmniStudio address this with Component Visibility features. With this, you can declaratively show or hide fields based on other values on the form or whether the user is on a mobile device or not.

Conditional Input States: If you need to dynamically control any other properties, such as whether a field is required, disabled, or read-only, you have a few options. As expected, LWC gives you full, reactive control over your input state. With reactive Screen Flow components, you can dynamically control component attributes like Read Only, Disabled, and Required for standard components that support it, while OmniStudio supports the full spectrum of component-specific attributes. If your requirements dictate that you need Flow, and the component doesn’t support a specific attribute state, you can create an embeddable LWC to achieve a dynamic input state.

If you need to dynamically control any other properties, such as whether a field is required or read-only, your best bet in the short term is LWC, where you have full control. That’s especially true if you have bespoke requirements for how to handle onblur or onclick.

Roadmap Note: For Lightning Pages, which includes Dynamic Forms, we anticipate enabling conditional formatting in the next 12 months.

Reactive LWCs in Screen Flows: When building LWCs that can both react to and change other components on a Screen Flow, consult this LWC Best Practices for Screen Flows guide to ensure your components integrate well within the flow runtime engine and work as expected into the future.

Standard Event Handling (onblur, onfocus) Custom Event Handling
Dynamic Forms Not Available Not Available
Screen Flow Not Available Not Available
OmniStudio Not Available Available*
Screen Flow + LWC Available Available
LWC Available Available
*The OmniStudio Standard Runtime does not support Pub/Sub, but does support Windows postMessage

Now for custom events. If some of your inputs or the entire form need to communicate with something else in the page, LWC is your only option.

Additional Resources

Styling

In order to provide the best user experience you’ll want to ensure that your form’s styling is consistent with the rest of the app or site that it’s being embedding in. Accomplishing this can mean anything from utilizing standard templates provided by Salesforce to creating custom CSS that completely utilizes every pixel in the design to provide a sharper look and feel.

Questions to ask:

Direct Styling Org and Experience Builder Themes Pixel-Perfect Styling
Dynamic Forms Not Available Available Not Available
Screen Flow Not Available Available Not Available
OmniStudio Available* Not Available Available
Screen Flow + LWC Not Available Available Available
LWC Not Available Available Available
*Flex Cards Only

FlexCards is the only product covered in this guide that enables you to declaratively control the styling and layout of the UI you’re building in the tool directly – whether that’s the margins and padding, typography, colors, etc.

Both Dynamic Forms and flows respect declarative theming features. If you need control beyond what Salesforce Themes, or Experience Builder Branding Sets, or LWR Experience Sites support, consider a programmatic solution.

For teams that are comfortable working with CSS, you have a couple options:

Wherever possible, we recommend using themes and design systems, so that your look-and-feel is applied consistently across all of your content.

Reminder: You can embed Lightning components in flows. So if you need pixel-perfect control over the look-and-feel of your form but want to use the other benefits of flows, like the navigation model, you can have the best of both worlds. The same principle applies to Omniscripts and FlexCards.

Layout

Choosing a good layout is crucial to designing streamlined forms that enable fast and efficient data entry and increase data integrity. See Salesforce Well-Architected - Forms for more information on this topic.

Questions to ask:

2 Columns 4 Columns Beyond 4 Columns Repeating Blocks of Data Tab Containers Accordion Containers
Dynamic Forms Available Not Available Not Available Not Available Available Available
Screen Flow Available Available Not Available Available Not Available Available
OmniStudio Available Available Available Available Available* Available
Screen Flow + LWC Available Available Available Available Available Available
LWC Available Available Available Available Available Available
*Tabs can be used if embedding data in a FlexCard in an Omniscript

Dynamic Forms supports two-column layouts and can be broken up into individual sections with fields. These sections can be placed in components such as tabs and accordions to create easy to use and organized layouts.

Flows can optionally be rendered using the new Section component. With sections, you can add up to four columns and as many sections as you want on the flow screen. The component is also responsive to screen width, so it can work on smaller screens. Lastly, it gives you the ability to apply conditional visibility to the entire section, making it easier to mass-apply visibility to multiple fields within the section. Flow Sections also support column headers and gives an accordion-like experience where users can collapse the entire section by clicking on the label.

Omniscripts feature a variety of layout options for displaying fields and data. You can create sections of data with up to 12 columns including conditionally collapsible accordions.

With LWC, you can use lightning-record-[edit|view]-form and the supporting lightning-[input|output]-field to control layout. The only layout restrictions are those from HTML/CSS. lightning-record-form respects the section configuration in the associated page layout; for example, if a section is two-column in the page layout, it’s two-column in this component.

Translation

If your form will be accessible by users in different regions or who speak different languages, you’ll need to ensure that the tool you’ll be using to build it will your localization requirements. See Salesforce Well-Architected - Localization for additional guidance and recommendations. In the case of forms, specifically, localization requirements typically involve translating text elements into other languages.

Questions to ask:

Labels Entered in the Builder Labels in the Code
Dynamic Forms Available* Not Available
Screen Flow Available Available
OmniStudio Available Available
Screen Flow + LWC Available Available
LWC Not Available Available
*Field Section Headings only

If you’ve localized your custom fields, those translated labels are respected on Dynamic Forms. However, localization isn’t supported for labels that you add to components in the same Lightning page. (for example, the label for a tab in the Tabs component).

With the power of Translation Workbench, Flow supports translation of user-facing labels for all standard and custom screen components. For the following screen components, you can localize the label, help text, and error message: Text, Long Text Area, Number, Currency, Checkbox, Radio Buttons, Picklist, Multi-Select Picklist, Checkbox Group, Password, Date, and Date/Time.

There is no built-in translation support for out-of-the-box actions, like Send Email or Post to Chatter. However, there is a workaround! If you define the translated labels with a Custom Label, you can reference that custom label in the action or component when you configure it in Flow Builder. Create a flow formula that references the custom label, and reference that formula in the appropriate places in your flow.

Omniscripts make use of custom labels for translations. Refer to this help doc to make your Omniscripts multi-language ready.

Now for LWC. Certain base components automatically inherit translations of the associated object’s fields, help text, and validation messages if they’ve been configured in Translation Workbench (for example: lightning-record-form).

If you need to introduce novel translatable labels in your code, Custom Labels are still the unsung hero. Declare the custom label you need, and then import it into your component from the @salesforce/label scoped module.

UI Test Automation

There are several end-to-end test automation tools available (for example, Selenium), which will allow you to simulate how the user interacts with your form. You can write these tests for any standard or custom UI, including Lightning pages and screen flows. However, it’s important to note that these types of tests can't verify the outputs of each method being performed. Make sure to take this into consideration when thinking through your requirements for UI test automation.

Questions to ask:

Unit Tests End-to-End Automation
Dynamic Forms Not Available Available*
Screen Flow Not Available Available*
OmniStudio Available* Available*
Screen Flow + LWC Available* Available*
LWC Available Available
*Requires Code

Consider your requirements for UI test automation.

Unit tests enable more granular automation and validation that works with industry standard CI/CD systems and tools, which can test the components business logic, its JavaScript controller, and its outputs. Going exclusively with low-code you will not be able to self-author tests, but Salesforce rigorously tests our end-to-end offerings.

If your component’s methods are complex enough that you want them to be tested individually, put the methods into dedicated JavaScript files. That way you can import them into a LWC and into a Jest test with something like import { sort } from 'c/utils';.

See UI Test Automation on Salesforce for a comparison of the various options you have for building end-to-end automation on Salesforce. Included are considerations for when to use a no-code solution from an ISV, build your own custom test automation solution, or use an open source test framework like Selenium WebDriver or WebdriverIO. These solutions are valid for any UI interaction in Salesforce, whether that’s a Dynamic Form in a Lightning page, a screen flow in a utility bar, or an LWC in a flow in a quick action.

Metrics

After you deploy your form to a production environment, you’ll want to make sure that it’s being used effectively. Depending on your use case, this can mean anything from simply tracking the number of times it’s been filled out to the amount of time users spend filling it out prior to submitting their information. Make sure to identify the KPIs you’re going to want to track prior to choosing a tool.

Questions to ask:

Page Views Time Spent on Form Track Form Completion Track Success Rate
Dynamic Forms Available** Not Available Not Available Not Available
Screen Flow Available Available* Available Available
OmniStudio Available Available* Available Available
Screen Flow + LWC Available Available* Available Available
LWC Available** Available* Available Available
*Available when Package-Based OmniStudio Runtime is enabled
** Available by tracking parent Lightning page usage

If you need to track overall usage and adoption of your form, start with the low-code tools. Both Dynamic Forms and Screen Flows are trackable using out-of-the-box custom report types, though you’ll get more granularity from the Screen Flow tracking reports. If you need to track usage of a LWC, out-of-the-box availability depends on where you’re using that LWC. If it’s on a Lightning page, whatever is available for tracking Lightning page usage applies to your LWC. The same story goes for LWCs that are embedded in flows.

Dynamic Forms themselves aren’t trackable out-of-the-box, though you can track the usage of the parent Lightning page through Lightning usage objects. To track the standard Lightning pages, use the Users with Lightning Usage by Page Metrics custom report type. For the same on custom Lightning pages, use the Users with Lightning Usage by FlexiPage Metrics custom report type.

For tracking adoption of your specific form (not just the page it lives in), Flow’s got you covered. Use the “Sample Flow Report: Screen Flows” to answer questions like:

If the standard report doesn’t meet your needs, clone it to make your own changes or build your own from scratch by using the Screen Flows report type.

If you’re using the package-based Omniscript runtime, you can utilize the OmniStudio for Vlocity Tracking Service. This service tracks any type of event. For example, you can track the time it takes to complete the steps in an Omniscript to identify process improvements. It’s on the OmniStudio team’s roadmap to support this service in Standard OmniStudio.

To track the same for an LWC that isn’t embedded in a screen flow, Omniscript, or Lightning page, there’s no out-of-the-box option. You can build a custom solution using Apex.

Packaging & Deployment

When you need to deploy your solution to higher environments for testing or deploying to production, you may be used to using change sets or DevOps Center to do so. Dynamic Forms, Flows, and LWCs are fully supported in those deployment options. OmniStudio requires a separate tool: IDX Workbench.

Questions to ask:

First Generation Managed Packages (1GP) Second Generation Managed Packages (2GP) Unlocked Packages Change Sets DevOps Center
Dynamic Forms Available Available Available Available Available
Screen Flow Available Available Available Available Available
OmniStudio Not Available Not Available Not Available Not Available* Not Available*
Screen Flow + LWC Available Available Available Available Available
LWC Available Available Available Available Available
*Use IDX Workbench to deploy OmniStudio Solutions to other orgs.

If you are an ISV or partner who plans to package up your solution for distribution on AppExchange, we recommend looking first at Dynamic Forms, Flows, and LWCs. OmniStudio doesn’t support packaging.

Additional Topics

This guide has been focused with helping you understand what functionality and level of customization is possible with Dynamic Forms, screen flows, OmniStudio, and LWC. At a high level:

Low-Code to Pro-Code Continuum

If multiple tools fit the bill, the decision comes down to which tool is the right one for your team. Other Architect Decision Guides introduce additional aspects to consider when making that decision.

We won’t go into the details of each of those aspects here, but what we will do is interpret them for the specific tools this doc is assessing.

Specialized Skills: How much expertise does your team have in the tools you’re comparing? How many makers are well-versed and familiar with LWC or JavaScript? How about makers who are experts in Flow Builder or have expressed an interest in dipping their toes? Generally speaking, Dynamic Forms and Flow skills are more attainable for a broader population of people who build forms. Dynamic Forms is the most declarative form-building tool and will always be easier to learn than Flow. That said, the Flow team is committed to getting that bar as low as possible. In terms of complexity, OmniStudio sits somewhere between Flow and LWC and offers significant form-building superpowers.

Delegation of Delivery: Just because some of your requirements call for LWC doesn’t mean your entire solution needs to be built with LWC. Consider how you can build your solution modularly, such that the parts that require LWC are coded, and the parts that don’t are built in a low-code solution. Doing so maximizes the efficiency of a diverse team and ensures that each individual is solving problems appropriate for their specialization.

Now let’s talk about Flow and LWC. With the Reactive Screen Components Beta, screen flow components can now talk to each other on the same screen unlocking a whole new tool chest for architects, admins, and developers. Developers can now create purposeful, modular components that can be reused across the organization, boosting productivity for everybody on the team. Developers can focus on solving new challenges and save time by using a mix of standard and custom Flow components to achieve form dynamism. With reactive components coming to Flow, there has never been a more appropriate time to mix Flow and LWC when building your forms.

Maintainability & Long-Term Ownership: If you have a multi-step form, it’s a good idea to start with Flow or a mix of Flow and LWC. If you’ve got a low-code team maintaining the solution, think about how you can make the solution as configurable and extendable as possible for that audience. Whichever tool you choose, organize your solution into composable units to improve maintainability and stability.

Page Layouts

Moving forward, the recommended way to configure record detail pages is Dynamic Forms in Lightning App Builder using Lightning Pages. It’s been a long time since we have enhanced page layouts, and that trend will continue. Here’s why:

As of the Summer ’23 release, Dynamic Forms still has some limitations. We recommend using Dynamic Forms wherever possible, and falling back to Page Layouts only when necessary. As always, we welcome feedback in the Idea Exchange on the improvements that would be most impactful to your organization.

Performance

Any performance considerations related to Dynamic Forms, screen flows, OmniStudio, and LWC center on what framework those technologies themselves sit on. The ones that are based in LWC (besides, of course, an LWC) are going to outperform ones that are based in Aura. The LWC framework offers better performance because core features are implemented natively in web engines instead of in JavaScript via framework abstractions. If you’re not familiar, give this blog post a read.

Back in 2019, we did a case study comparing the performance of the same functionality in Aura vs. in LWC. As a result of converting DreamHouse from Aura to LWC, not only was the development experience far more aligned with current web front-end development standards and patterns, but the performance gains were significant. Lab measurements showed gains in the range of 2.4 percent to 24.7 percent for cold cache and gains in the range of 31.83 percent to 63.32 percent for warm cache on the same two pages.

Now, which framework are our form technologies using? In other words, which form technologies benefit from this superior performance?

Closing Remarks

As an architect, it’s important to have a solid understanding of all the options available to you and how you can apply them in your specific use case. For building forms on Salesforce, the options range from low-code (using Dynamic Forms, in Lightning App Builder and Screen Flows in Flow Builder and Omniscripts in OmniStudio) to pro-code (using the LWC framework), with a combination of screen flows or Omniscripts and LWC in the middle. Keep this guide in mind and use it as a reference when you’re planning to build (or redesign) forms on Salesforce. If you’re looking for guidance on how to design streamlined and helpful forms, consult Salesforce Well-Architected: Engaging.

Tell us what you think

Help us make sure we're publishing what is most relevant to you: take our survey to provide feedback on this content and tell us what you’d like to see next.