Web forms. We complete them every day. They range from the simple (and ubiquitous) Google search box, through to complex mortgage applications.
But what are your options when you need users to enter data that will end up in Salesforce? In this post, I compare two tools – Salesforce screen flows and OmniScripts – and discuss when to use one over the other.
Salesforce Form Tool Options
Until recently, Salesforce has provided four main form building options:
- Page layouts : The original, and simplest, data entry tool.
- Dynamic Forms : The new and improved ‘page layouts’ (but with a number of gaps at this point).
- Lightning web components (LWC) : Fully flexible, developer-only framework.
- Screen flows : Configurable form builder that sits somewhere between Dynamic Forms and LWCs.
These are the options from least flexible to most flexible:
Salesforce’s Architect’s Guide to Building Forms provides a great analysis of when to use Dynamic Forms, versus screen flows, versus LWC.
One option the guide doesn’t cover is OmniScripts, which joined the Salesforce product family in February 2020 (as part of the Vlocity acquisition, now Salesforce Industries). OmniScripts are one part of OmniStudio, which is available to Salesforce Industries customers (Media Cloud, Communications Cloud, Utilities Cloud, Public Sector solutions).
So what is an OmniScript?
An OmniScript is a guided interaction that you configure to step users through complex business processes. (For more details, see this Trailhead unit.)
Screen Flows vs. OmniScripts: At a Glance
OmniScripts sound similar to screen flows. Both let you create forms that guide users through a business process and both are designed for non-developers to use.
But, as noted in this table, there are a number of differences:
| Area | Item | Screen Flow | OmniScript |
|---|---|---|---|
| Form Location | Lightning record page | Yes | Yes |
| Experience Cloud page | Yes | Yes | |
| External sites and apps | Yes | Yes | |
| User Experience | Multi-screen forms | Yes | Yes |
| Dynamic form and field visibility | Yes | Yes | |
| Pause / save for later | Yes | Yes | |
| Progress indicator | Yes | Yes | |
| Field masking | No | Yes | |
| Responsive | No | Yes | |
| Pixel-perfect styling | No | Yes | |
| Data Sources | Declarative integrations | Yes | Yes |
| Metrics | Granular usage analytics | No | Yes |
Broadly speaking, the more flexibility you need over the form, the more likely you should use OmniScript. In the Salesforce forms the universe, OmniScripts sit between screen flows and LWCs:
Screen Flows vs. OmniScripts: A Use Case
To understand the differences in detail, I rebuilt an existing paper-based government form using both tools. I chose a process I had learned about earlier in my career : applying to operate a bus service in my home state (Victoria, Australia). In Victoria, bus operators must complete a Word-based application to be accredited or registered by the government.
So, what does a screen flow-based version of this application process look like? And what does an OmniScript version look like?
First, let’s look at the similarities.
Both tools make it easy to create clean-looking forms, without requiring any custom styling or coding. Superficially, both forms look similar, with both:
- Including a bus image on their first screen to visually communicate what the application relates to.
- Displaying informational text on the first screen to provide further guidance on the meaning of accreditation versus registration.
- Containing similar input controls across both screens.
- Conditionally showing or hiding the ABN field , as that field is not relevant for an individual applicant.
This is the screen flow version of the form (the red numbers relate to the above list items):
Now let’s look at the key differences between the two forms.
Difference #1: Progress Indicator
The OmniScript form (see below) provides important additional context by automatically displaying a list of all the steps (screens) that the user needs to complete, and flagging their current step. This is known as a progress indicator.
Also, when the user sets their application type to “Accreditation” (as opposed to “Registration”), the progress indicator automatically expands to include the “Competency” step (since this information is only required for “Accreditation” applications). Progress indicators help reduce users’ anxiety by communicating how far they are from finishing.
Note: While the Progress Indicator is not available out of the box in Salesforce for screen flows as it is for OmniScript, this Salesforce Labs package can be installed and it offers 6 variations of progress bars for you to use within the screen flow.
Difference #2: Informational Text
When the user is asked to select their application type (“Accreditation” or “Registration”), I felt it was important to provide them with enough information to make an informed decision. However, not all applicants need that information, and I wanted to keep the interface clean and simple. The OmniScript form can be configured to include information on the interface, but to collapse (i.e., hide) that information by default (see below).
Difference #3: Visual Radio Buttons
In an OmniScript form, a radio button-type question can be rendered with images (see below). This is demonstrated in the question about whether the applicant is “a body corporate” or “an individual” (with a building icon representing “body corporate”, and a person icon representing “individual”). Including images reduces the chances of a user selecting the wrong option.
Difference #4: Display Message
In the OmniScript form, when a user enters a date of birth that indicates they’re under 18, a yellow warning message appears (see below). OmniScript has built-in options for the following scenarios:
- Success (green tick).
- Requirement (red cross).
- Warning (yellow exclamation mark).
- Comment (grey chat icon).
These message types make it easy for users to understand what has happened, and how to proceed.
Difference #5: Input Constraints
The OmniScript form fields provide powerful options for ensuring users enter the correct data in the required format. For example, in the “Mobile” field (see below), I was able to:
- Specify the minimum and maximum number of characters to be entered (10 and 10).
- Restrict the allowable values (numbers only).
- Pre-populate those values that are always required (the first two numbers — 04).
- Add required spacing (after the 4th and 7th digits).
- Display an error message when the user leaves the field without providing a valid entry.
I added similar constraints to the ABN, Date of Birth, Postcode, Email, and Landline fields.
Other Differences
Some additional behind-the-scenes differences between Salesforce screen flow and OmniScript are worth noting.
As explained in this Trailhead unit, with OmniScripts you can:
- Use them on any device via any channel, without having to change the configuration. Unlike screen flows, OmniScripts are responsive.
- Display data from multiple sources – both internal data from Salesforce and external data from a website or a third-party legacy system. This, however, can also be achieved within Salesforce flow as well, through the use of HTTP Callout.
- Rebrand them to suit your customers via customisable, global stylesheet assets.
- Manage document workflows by creating dynamic documents from templates and merge data, and getting them electronically signed.
And, finally, OmniScripts include usage analytics that enable you to capture granular details of actions that users perform (e.g. the time it takes to complete the steps in an OmniScript, or even how often an individual picklist item is selected). You can use this data to improve your forms’ usability and completion rates.
Which Tool Should You Use When?
So, when should you use a Salesforce screen flow and when should you use an OmniScript? There are a number of factors to consider when deciding which tool to use:
Summary
Screen flow is better for simpler forms that only interact with Salesforce data, and where the exact look and feel isn’t so important. Think more general internal (employee) forms – such as feedback forms or IT support requests.
OmniScript is better for more complex, higher-value interactions and/or where branding is important. Think industry-specific, consumer-facing processes, such as signing up for a mobile phone plan or requesting an increased credit card limit.
Comments: