Free OmniStudio-Consultant Practice Test Questions (2026)

Explanation:

This question is about designing an efficient mobile interface in Salesforce using FlexCards for a field service scenario. The core requirements are:

Summarized, at-a-glance details of installed products.

Ability to access a detailed list of past service dates when needed.

Here's how the chosen features address these requirements:

B. Use Card States:
This is the primary feature for showing the "summarized" view. A FlexCard can have multiple states (e.g., a default "Summary" state and a "Detailed" state). The consultant would create a compact "Summary" state that displays only the key fields the technician needs to see at a glance (e.g., Product Name, Serial Number, Status). This directly fulfills the first part of the requirement.

A. Use Flyouts:
This is the perfect solution for the "sometimes access" detailed information. A flyout is a pop-up panel that appears when a user interacts with an item on the card. The consultant can configure the summary state so that when the technician taps on a specific product, a flyout opens. This flyout can contain the secondary, more detailed information—in this case, the list of past service dates—without navigating away from the main screen or cluttering the initial summary view.

Why the Other Options Are Incorrect:

C. Enable the Responsive property:
While making the card responsive is a best practice for mobile design, it is not a specific solution to the requirement of showing summarized vs. detailed data. Responsiveness ensures the card layout adapts to different screen sizes, but it doesn't inherently create the two-tiered data hierarchy (summary + detail) that the business needs.

D. Customize the styling:
Customizing styling (colors, fonts, etc.) improves the visual appeal and usability but, like the responsive property, does not functionally solve the problem of organizing and revealing different layers of information. It's about how the information looks, not what information is shown and when.

Summary / Key Takeaway:

The combination of Card States (for the primary, summarized view) and Flyouts (for the optional, detailed information) is a standard and powerful pattern in OmniStudio for creating intuitive mobile experiences where users need quick access to high-level data with the ability to drill down into specifics on demand.

Reference:

This pattern is covered in Salesforce OmniStudio Trailmixes and documentation, particularly in modules focusing on designing mobile-ready components with FlexCards.

Explanation

Conditional Views (specifically Conditional Steps or Conditional Elements within an OmniScript) are the primary way to control which parts of a user journey are displayed based on previous user input or data.

How it meets the requirement:
OmniScript elements (like a Step, Block, or individual input element) can be configured with a Conditional Display (or LWC Condition in the newer FlexCards/LWC style) formula. This formula checks the values of other elements in the script (e.g., "Did the user answer 'Yes' to Question X?"). If the condition evaluates to true, the step/element is shown; if false, it is hidden, and the user skips over it without having to interact with it. This directly addresses the need for some steps to only apply to users depending on their responses.

Why the other options are incorrect:

A. User Roles:
While roles can control access to the OmniScript itself (who can launch it), they generally don't control the flow within the script based on dynamic user input during the process.

C. Script Configuration:
This is a broad term for setting up the script (e.g., type, subtype, language) but doesn't specifically refer to the feature that enables dynamic conditional flow.

D. Script Profiles:
Similar to User Roles, profiles are used to control the overall access permissions to the script, not the step-by-step conditional visibility based on real-time user answers.

Reference (Vlocity/Industries)

This question is related to the Vlocity (now Salesforce Industries) product, specifically OmniStudio (OmniScripts). The concept of conditional display is a fundamental part of building dynamic user interfaces in this platform.

You can typically find documentation on Conditional Display or Conditional Steps/Elements within the official Salesforce OmniStudio documentation, which details using formulas to govern visibility.

Explanation

In Salesforce OmniStudio FlexCards, each FlexCard can be configured to pull data from a single data source, which can be Salesforce (via SOQL or Apex) or an external system (via Integration Procedures or DataRaptors calling REST/SOAP APIs). In this scenario, the setup includes a parent FlexCard with a canvas containing 5 child FlexCards within its state. Each of these FlexCards (the parent and the 5 children) can independently connect to a unique data source.

Parent FlexCard:
Can have its own data source (e.g., Salesforce data for core customer details).

Child FlexCards:
Each can have a distinct data source, potentially pulling from different external legacy systems or different Salesforce objects/queries.

Thus, the total number of data sources possible is 6 (1 for the parent + 5 for the child FlexCards). FlexCards support this flexibility through OmniStudio’s data integration capabilities, allowing each card to fetch data via DataRaptors, Integration Procedures, or direct SOQL queries, regardless of whether the data resides in Salesforce or external systems.

Why Other Options Are Incorrect:

A. 2: This underestimates the capability, as it might assume only Salesforce and one external system. However, each FlexCard can connect to a unique source, not limited to two.

C. 5: This might assume only the child FlexCards have data sources, ignoring the parent FlexCard’s ability to have its own.

D. 1: This is incorrect, as FlexCards are not restricted to a single data source across the parent and children.

References

Salesforce Help: FlexCard Data Sources – Explains how FlexCards can connect to Salesforce or external data via DataRaptors or Integration Procedures.

Trailhead: OmniStudio Data Tools – Covers configuring multiple data sources for FlexCards, including Integration Procedures for external systems.

Salesforce Help: Create a FlexCard with Child FlexCards – Notes that parent and child FlexCards can each have independent data sources.

Explanation

The question requires matching three specific data capture needs with the most appropriate OmniScript Element.

Let's break down each requirement and why the chosen elements are the best fit:

"Select one payment method from a list of options"

Requirement: The user must choose only one option from a predefined list.

Correct Element: Radio

Why: A Radio button group is the standard UI element for presenting a list of mutually exclusive options where only one selection is allowed. This perfectly fits the "select one" requirement for a payment method (e.g., Credit Card, PayPal, Bank Transfer).

Why not the others?

Multi-Select (Option B) is for choosing multiple options, which violates the "select one" rule.

Checkbox (Option C) is typically for enabling/disabling a single option or, when grouped, for multi-selection.

Select (Option D) could technically work as a dropdown, but a Radio group provides a better user experience by showing all options at once, making it clearer that only one can be chosen.

"Enter the address information with autocomplete"

Requirement: The user should start typing an address and have the system suggest complete, validated addresses.

Correct Element: TypeAhead

Why: The TypeAhead element is explicitly designed for this purpose. It provides real-time suggestions from a data source (like an address validation service) as the user types, improving accuracy and speed. The standard Address element (Option B) might not always have robust autocomplete functionality and is often a collection of individual fields (street, city, zip).

Why not the others?

Address (Option B) is a composite element for breaking down an address into its parts but lacks the specific "autocomplete" behavior described.

Geolocation (Option C) is used to capture a user's current geographical coordinates, not for manually entering a street address with suggestions.

"Enter a phone number"

Requirement: Capture a phone number.

Correct Element:Telephone

Why: The Telephone element is a specialized input field for phone numbers. It often includes built-in validation for correct phone number formats (digits, length, etc.) and can be configured for international formats. This provides a better, more validated user experience than a simple number field.

Why not the others?

Number (Options C and D) is a generic element for numerical values. It would accept any number (like 100, 3.14, etc.) and does not provide any phone number-specific formatting or validation.

Summary

The combination of Radio (for single selection), TypeAhead (for address with autocomplete), and Telephone (for a validated phone number) directly and precisely matches the business requirements outlined in the question.

Reference:

These element types and their specific use cases are defined in the Salesforce OmniStudio Documentation and are a core part of the "Build Industries-First Applications with OmniStudio" trailhead.

Explanation

The recommended design leverages the core capabilities of FlexCards for displaying related, diverse data and enabling user interaction.

Parent FlexCard:
Serves as the main container and entry point, typically based on the main object (the Account). Provides the 360° view of the customer.

Child FlexCards:
Used to display distinct, related data sets fetched from the same or different data sources (the Integration Procedure).Displays Active Opportunities and Active Contracts as separate, dedicated sections.

Card Actions:
Interactive elements (buttons, links) added to a Card that trigger actions like launching an OmniScript, running another Integration Procedure, or navigating a page.Provides the ability to view and renew contracts (e.g., a "Renew" button on the Contract Child FlexCard).

Why Other Options Are Incorrect:

B & C. Different Card States:
Card States are used to change the content/layout of a single Card based on its data (e.g., showing a different state if a contract is "Active" vs. "Expired"). They are not the best way to display entirely different sets of related records (Opportunities and Contracts) that should live side-by-side on the console.

C & D. Single Child:
Using only a single Child FlexCard would be insufficient, as the requirements call for two distinct lists of related records: Opportunities and Contracts. Each distinct list needs its own dedicated Child FlexCard for clarity and organization.

C. Single Child and multiple Card States:
This would be overly complex and confusing, trying to cram distinct data (Account, Opportunities, Contracts) into one card that changes its look based on data.

D. Parent FlexCard with single Child and Card Actions:
Fails because it doesn't account for the need to display the Opportunities and Contracts as separate, related lists.

Reference (Salesforce Industries/OmniStudio)

This question relates to FlexCards within OmniStudio (formerly Vlocity/Salesforce Industries).

Parent/Child Cards are the standard way to build a hierarchical 360° view, where the Parent Card is the main record (Account) and Child Cards display related lists (Opportunities, Contracts).

Actions (Card Actions) are essential for enabling user interaction, such as the "view and renew contracts" requirement.

Explanation

To meet the requirement of displaying an account and its associated contacts with varying numbers, along with specific display and interaction features, the consultant should recommend the following FlexCard features:

Data table (A):

A Data table element in FlexCards is ideal for displaying a list of records, such as contacts associated with an account. It can dynamically show fields like First Name, Last Name, Email, and Phone Number in a tabular format. The Data table supports Actions, which can be configured to enable editing contact information or sending a message (e.g., via OmniScript or Integration Procedure triggers). Additionally, styling options in the FlexCard Designer allow the primary contact to be highlighted with a blue border by applying conditional formatting based on a field (e.g., a "Primary Contact" boolean or specific logic in the data source).

Why it fits: The Data table handles dynamic lists and supports interactivity (edit/message actions) and conditional styling for the primary contact.

Repeat Block (D):

A Repeat Block (also called a Repeating Block) is used to iterate over a list of records, such as contacts, and render them as individual elements or cards within the FlexCard. Each contact can be displayed with fields (First Name, Last Name, Email, Phone) and include actionable buttons for editing or messaging. Conditional styling can be applied within the Repeat Block to highlight the primary contact with a blue border using style rules (e.g., based on a "Primary Contact" field value).

Why it fits: Repeat Blocks are perfect for rendering variable numbers of records in a customizable, non-tabular format, with support for actions and styling.

Why Other Options Are Incorrect:

B. Flyouts:

Flyouts are used to display additional details or actions in a pop-up/modal when a user interacts with an element (e.g., clicking a contact). While Flyouts could be used for editing or messaging, they are not ideal for displaying the initial list of contacts or applying a blue border to the primary contact, as they are secondary interactions rather than the primary display mechanism.

C. States:

States in FlexCards control conditional visibility or behavior of elements based on data or business logic (e.g., showing different fields for active vs. inactive accounts). They are not suited for iterating over a dynamic list of contacts or applying styling like a blue border to a specific record. States could be used for other purposes (e.g., switching between account types), but they don’t address the core requirement of displaying and styling a variable contact list.

How These Features Work Together:

The Data table is better for a structured, tabular display of contacts with consistent columns and built-in action buttons.

The Repeat Block offers more flexibility for a card-based or custom layout, where each contact is rendered as a separate visual block with tailored styling.

Either can fulfill the requirement, but the choice depends on the desired UI (table vs. card layout). Both support actions for editing/messaging and conditional styling for the primary contact’s blue border.

References

Salesforce Help: Add a Data Table to a FlexCard – Describes using Data tables for dynamic record lists with actions and conditional styling.

Salesforce Help: Add a Repeating Block to a FlexCard – Explains how Repeat Blocks iterate over record sets and support custom layouts and actions.

Trailhead: Style FlexCard Elements – Covers applying conditional styling (e.g., blue border) based on data conditions in Data tables or Repeat Blocks.

Explanation

This question is about dynamically changing the interface and available actions based on the value of a record's field—in this case, the Case Status.

Let's break down the requirement:

The core need: The "Reopen Case" button should be visible and clickable only when the Case Status is "Closed". It must be hidden or disabled when the status is "Active" or "Escalated".

The underlying concept: This is a classic example of needing to change the behavior and appearance of the FlexCard based on data conditions.

Here is why State is the correct and most powerful solution:

What is a State? In a FlexCard, a State allows you to create multiple, distinct "views" or "versions" of the same card. You define a condition (e.g., Status EQUALS Closed) to determine when each state is active.

How it solves the problem:

You would create a state named "Closed State" with a condition 'Status' == 'Closed'.

Within this "Closed State," you would add the "Reopen Case" button as a clickable element.

The Default State of the card would have the same layout but would not include the "Reopen Case" button.

The FlexCard engine automatically evaluates the record's status and displays the correct state, showing the button only for closed cases.

Why the Other Options Are Incorrect:

A. Conditional View: While this sounds similar, a "Conditional View" is not the primary, named feature for this specific use case in FlexCards. "State" is the formal and most robust mechanism for creating entirely different layouts and action sets based on data. Conditional View might refer to simpler visibility toggles, but State is the comprehensive solution.

B. Flyouts: Flyouts are used for displaying additional, related information in a pop-out panel (e.g., showing case history). They do not control the conditional visibility of a primary action button on the card itself based on a record's field value.

D. Styling: Styling controls the visual appearance (colors, fonts, borders) of elements. You could, for example, use conditional styling to gray out a button, but it cannot be used to add or remove the "Reopen Case" action from the card's logic and layout. The requirement is about functionality (having the option), not just appearance.

Summary / Key Takeaway:

The State functionality in FlexCards is explicitly designed for this purpose: to present different user interfaces, including different sets of actionable buttons, depending on the data context of the record being displayed. It is the most direct and powerful way to meet the requirement of showing a "Reopen" button only for Closed cases.

Reference:

This is a fundamental concept in OmniStudio. The use of Card States to dynamically show/hide elements based on record data is covered in the "FlexCards" module of the OmniStudio Trailmix and official documentation.

Explanation

To meet the insurance company’s requirement of creating an OmniScript that allows users to review and edit account details (website and phone number) with each field displayed on a separate line, the consultant should include the following OmniScript elements:

Telephone (C):

The Telephone element is specifically designed for capturing and validating phone numbers. It ensures the input adheres to standard phone number formats (e.g., with country codes or specific patterns) and provides built-in validation, making it ideal for the account phone number field.

Why it fits: This element is tailored for phone number input, ensuring proper formatting and user-friendly data entry for the phone number requirement.

Line Break (D):

The Line Break element is used in OmniScript to separate fields visually, ensuring each field (website and phone number) appears on a separate line in the UI. This element explicitly controls the layout to meet the requirement of displaying fields on separate lines.

Why it fits: The Line Break element directly addresses the layout requirement by forcing each field to render on a new line, enhancing clarity and user experience.

Text (E):

The Text element is used for capturing general text input, such as a website URL. It allows users to enter and edit free-form text, making it suitable for the company’s website field, which typically requires a string input (e.g., "www.example.com").

Why it fits: The Text element is appropriate for capturing and displaying the website field, as it supports flexible text input without specific formatting constraints beyond optional validation rules.

Why Other Options Are Incorrect:

A. Number:

The Number element is designed for numeric input (e.g., integers or decimals) with specific formatting options, such as currency or percentages. A phone number, while containing digits, is treated as a string with specific formatting (e.g., hyphens, parentheses), making the Telephone element more appropriate. Similarly, a website URL is text-based, not numeric.

B. Text Area:

The Text Area element is used for multi-line text input, such as comments or descriptions. A website URL is typically a single-line input, so the Text element is more suitable. Using a Text Area would be unnecessary and could confuse users expecting a single-line field for a URL.

How These Elements Work Together:

The Text element captures the website URL (e.g., "www.example.com").
The Telephone element captures and validates the account phone number (e.g., "+1-123-456-7890").
The Line Break element ensures each field is displayed on a separate line in the OmniScript UI, meeting the layout requirement.
In the OmniScript Designer, these elements are placed within a Step or Block, with Line Breaks inserted between the Text and Telephone elements to control the layout declaratively.

References

Salesforce Help: OmniScript Element Types – Details the Telephone, Text, and Line Break elements, including their use cases for input and layout control.

Trailhead: Build an OmniScript – Explains how to configure input elements like Text and Telephone and use Line Break for layout.

Salesforce Help: Design OmniScripts for User Input – Covers best practices for selecting elements like Text for URLs and Telephone for phone numbers, with layout considerations.

Explanation

This question focuses on the specific use case of creating a new record directly from a FlexCard interface. The key phrase is "the user should be able to create a new case from the canvas."

Let's analyze the requirement and why "Blank Card State" is the correct choice:

The Scenario: You have a FlexCard displaying a list of cases for an account. This is the "read-only" or "display" view. To create a new case, you need a different interface—a form with empty fields for the user to fill out.

What is a Blank Card State? A Blank Card State is a special state in a FlexCard that is not tied to any specific data record. It acts as an empty template or a blank form. Its primary purpose is to allow users to create brand new records.

How it Solves the Problem:

The consultant would design the main FlexCard to display existing cases (using Active Card States or a List Card).

They would add a "New Case" button somewhere on the interface.

This button would be configured to navigate to the Blank Card State.

The Blank Card State would contain all the necessary input elements (like Text, Textarea, Picklist, etc.) for the user to enter the details of the new case.

Once the user fills out the form and submits it, the FlexCard would create the new Case record and then typically refresh to show the updated list, including the newly created case.

Why the Other Options Are Incorrect:

A. Active Card State: An Active Card State is used to display data from an existing record. It is "active" because it is bound to a specific record in the database. It is perfect for showing the list of existing cases but cannot be used as a template to create a new record from scratch.

C. Edit Mode State: An Edit Mode State is used to edit the data of an existing record. You first have an Active Card State showing the data, and then you can switch to an Edit Mode State to modify that same record. It is not designed for creating net-new records.

D. New Card State: This is a distractor. While it sounds correct, "New Card State" is not a standard, named state type in FlexCards. The official term for the state used to create new records is the Blank Card State.

Summary / Key Takeaway:

The Blank Card State is the fundamental and purpose-built tool within FlexCards for enabling "create new record" functionality. It provides the empty form that allows users to input data for a record that does not yet exist in the database.

Reference:

This is a core concept for FlexCard development. The distinction between Active, Edit, and Blank states is covered in the "Get to Know FlexCards" module on Trailhead and the official OmniStudio documentation.

Explanation

The Loop Block is the essential feature in a Salesforce OmniStudio Integration Procedure (IP) used to iterate over a list or array of data and perform a series of actions (including multi-step calculations) on each item.

Iteration: You configure the Loop Block to target the list of contacts (the data array).

Execution: For every contact record in that list, the Loop Block executes the steps (Actions and other Blocks) contained inside it.

Multi-Step Calculation: Inside the Loop Block, you would place:

One or more Set Values actions using formulas to perform calculations.

A Calculation Action (calling an Expression Set or Calculation Procedure) to handle complex, multi-step math on the current contact's data.

A DataRaptor Load Action or Update Action to save the final calculated value back to the contact record.

Why the Other Options are Incorrect:

B. Batch Action: There is no standard "Batch Action" element in an Integration Procedure. Batching typically refers to asynchronous Apex processing for large data volumes, which is separate from the IP's synchronous flow control.

C. Conditional Block: This block is used for executing steps conditionally (based on a true/false evaluation) but does not handle repetition or iteration over a list.

D. DataRaptor Transform Action: This is a powerful tool for manipulating (re-shaping, merging, aggregating) JSON data in bulk, but it cannot execute a multi-step, sequential business process or calculation on each item in the same way a Loop Block can. While it can perform some aggregations, a Loop Block is necessary to run a full multi-step process for each record.

Reference (Salesforce OmniStudio)

The Loop Block property allows an Integration Procedure to process arrays, repeating all the actions contained within the block for every item in the list.