Free OmniStudio-Consultant Practice Test Questions (2026)

Explanation

The requirement is to identify an OmniScript element that can retrieve data from multiple sources. Let’s evaluate each option:

Integration Procedure Action (B):

An Integration Procedure Action in OmniScript is designed to execute an Integration Procedure, which can aggregate data from multiple sources, such as Salesforce objects (via DataRaptors), external systems (via REST/SOAP APIs), or other data transformations. Integration Procedures allow you to combine and manipulate data from various sources into a single JSON response, making this the ideal element for retrieving data from more than one source.

Why it fits: Integration Procedures are specifically built to handle complex data operations, including fetching and combining data from multiple sources (e.g., Salesforce and external legacy systems) in a single action.

Calculation Action (A):

A Calculation Action performs mathematical or logical operations on data already available within the OmniScript (e.g., summing values or concatenating strings). It does not retrieve data from external or multiple sources; it only manipulates existing data.

Why it’s incorrect: It lacks the capability to fetch data from any source, let alone multiple sources.

DataRaptor Extract Action (C): A DataRaptor Extract Action retrieves data from a single Salesforce object or related objects using a SOQL query or predefined mapping. While powerful for Salesforce data, it is limited to a single data source (Salesforce) and cannot natively combine data from external systems or multiple disparate sources without additional configuration.

Why it’s incorrect: DataRaptor Extract is restricted to one Salesforce-based data source per action, unlike Integration Procedures.

Matrix Action (D):

A Matrix Action is not a standard OmniScript element in Salesforce OmniStudio. The term may refer to Vlocity’s legacy Matrix Calculations or custom configurations, but it is not used for data retrieval from multiple sources. Even in legacy contexts, Matrix Actions were for calculations, not multi-source data fetching.

Why it’s incorrect: It’s either a distractor or irrelevant to OmniScript’s data retrieval capabilities.

Why Integration Procedure Action Stands Out:

Integration Procedures can orchestrate multiple data operations, such as calling multiple DataRaptors, invoking REST/SOAP APIs for external systems, or performing transformations, all within a single action. This makes them uniquely suited for retrieving and combining data from multiple sources (e.g., Salesforce objects, external APIs, or even static data).

In the OmniScript, the Integration Procedure Action references an Integration Procedure, which outputs a unified JSON response that OmniScript elements can use to display or process data.

References

Salesforce Help: Integration Procedures – Explains how Integration Procedures aggregate data from multiple sources, including Salesforce and external systems.

Trailhead: OmniStudio Integration Procedures – Details using Integration Procedure Actions in OmniScript to fetch and combine data from multiple sources.

Salesforce Help: OmniScript Actions – Describes the Integration Procedure Action as a tool for complex data retrieval compared to DataRaptor Extract’s single-source limitation.

Explanation

The current process is functional but inefficient and violates key OmniScript best practices. Let's analyze why these two improvements are recommended.

B.Use a single DataRaptor to save the information The Problem: The OmniScript currently uses a DataRaptor to update the account after each of the three steps. This means it's making three separate DML (Data Manipulation Language) operations to create/update a single record.

The Best Practice: The best practice is to minimize the number of external calls and DML operations. A single, more complex DataRaptor (or an Integration Procedure) should be used to handle the final save of all the data at once, typically at the end of the OmniScript.

Why It's an Improvement:

Performance: Reduces system latency and processing time by making one call instead of three.

Data Integrity: Reduces the risk of partial saves or data corruption if a user abandons the OmniScript midway.

Governor Limits: Is more efficient with respect to Salesforce governor limits on DML statements.

A. Create a reusable OmniScript for this process

The Problem: The OmniScript is likely built as a "one-off" solution. If the same process for creating a billing account is needed elsewhere (e.g., in a different LWC, in a mobile app, via an API), it would have to be rebuilt.

The Best Practice: Designing OmniScripts to be reusable is a core principle. This involves using the OmniScript's Type and Sub Type properties effectively and designing it to be invoked from multiple entry points.

Why It's an Improvement:

Maintainability: If the process changes, you only need to update one reusable OmniScript, not multiple copies.

Consistency: Ensures the same business process is followed everywhere it's used.

Efficiency: Saves development time in the long run.

Why the Other Options Are Incorrect:

C. Combine the three steps into one step:
This is not a best practice from a user experience (UX) perspective. Breaking a process into logical, bite-sized steps (like the current three steps) improves usability, reduces user error, and feels less overwhelming. Combining them into one long, scrolling form would make the process more cumbersome for the agent.

D. Configure the save for later property:
The "Save for Later" feature is used when a user might need to pause a long process and resume it later (e.g., in a customer self-service portal). For an internal agent creating a billing account, this is likely an unnecessary feature. The primary problems with the script are its technical inefficiency and lack of reusability, not the inability to save progress. Enabling this property does not address the core performance and design flaws.

Summary / Key Takeaway:

The best practice improvements focus on backend efficiency (one DataRaptor call) and long-term architectural health (reusable design), not on compromising the user-facing step structure or adding unnecessary features.

Reference:

These best practices are covered in Salesforce OmniStudio documentation and Trailhead modules related to DataRaptor optimization and designing reusable OmniScripts.

Explanation

The TypeAhead element in OmniScript requires a data source that can perform a real-time search based on the user's input and return a list of matching records, along with their related fields.

The DataRaptor Extract Action is the standard and most efficient tool for this requirement because:

Search Functionality (Extract): A DataRaptor Extract is designed to query Salesforce data (like Contacts) and filter the results.

Input Parameter: The TypeAhead element automatically passes the text the user types into the input field to the DataRaptor Extract as a filter value (often called a LookupKey).

Real-Time Results: The DataRaptor uses this input to query the Contact object, typically filtering by Name using a LIKE operator, and returns the matching contacts to the OmniScript to display in the dropdown.

Retrieving Additional Data: Once the user selects a contact, the DataRaptor has already returned all mapped fields for that contact (including the Email Address), making the email instantly available in the OmniScript's Data JSON for use in a later step.

Other Supported Data Sources

While the DataRaptor Extract Action is the best fit for this specific scenario (searching Salesforce records), a TypeAhead element can also use:

HTTP Action (for external APIs)

Remote Action (for Apex code)

Integration Procedure Action (if you need complex logic before extracting data)

Data JSON (if the data is already in the OmniScript)

Explanation

The requirement involves implementing distinct verification processes for three Contact record types (Recruiter, Candidate, Trainer) with unique workflows for each (e.g., background checks for Recruiters, training classes for Trainers, certifications for Candidates). OmniStudio tools, such as FlexCards and OmniScripts, are well-suited for creating tailored, user-friendly interfaces and processes.

Let’s evaluate the options:

Specific FlexCards with Actions for each type of Contact (A):

Why it fits: FlexCards are used to display contextual data and provide actionable interfaces for users. Creating specific FlexCards for each Contact record type (Recruiter, Candidate, Trainer) allows the consultant to design tailored displays showing relevant data (e.g., contact details, verification status) for each record type. Each FlexCard can include Actions (e.g., Action elements or buttons) that trigger specific OmniScripts to handle the unique verification processes (background check for Recruiters, training for Trainers, certifications for Candidates). For example:

A Recruiter FlexCard could show contact details and a button to initiate a background check OmniScript.
A Trainer FlexCard could display training status and link to a mandatory training OmniScript.
A Candidate FlexCard could show certification progress and invoke a certification tracking OmniScript.


This approach leverages FlexCards’ ability to conditionally display data based on record type (using States or Filters) and OmniScripts’ process automation for verification workflows. It ensures a clean, record-type-specific UI and process flow, meeting the requirement effectively.

Additional benefit: FlexCards can be embedded in Lightning pages or Experience Cloud sites, providing flexibility for where the verification processes are accessed.

Multiple OmniStudio Actions that invoke separate OmniScripts (B):

Why it’s incorrect: OmniStudio Actions (e.g., Integration Procedure Action, DataRaptor Action) are used within OmniScripts to perform specific tasks like data retrieval or updates, not to directly invoke entire OmniScripts for end-user interaction. While separate OmniScripts could be created for each verification process, relying solely on Actions without a user-facing interface (like FlexCards) doesn’t provide a clear way to display contact data or initiate processes in a user-friendly manner. This option lacks the UI component needed for a complete solution.

Single FlexCard with an Action to invoke an OmniScript (C):

Why it’s incorrect: A single FlexCard could display contact data and include an Action to invoke an OmniScript, but it wouldn’t easily accommodate the distinct verification processes for each record type. A single FlexCard would require complex conditional logic (e.g., using States or Formulas) to dynamically adjust its display and actions based on the Contact record type. This approach is less maintainable and scalable compared to separate FlexCards tailored for each record type. Additionally, a single OmniScript would struggle to handle the diverse workflows (background checks, training, certifications) without becoming overly complex or requiring extensive branching logic.

Single OmniStudio Action that invokes separate OmniScripts (D):

Why it’s incorrect: Similar to option B, a single OmniStudio Action (e.g., an Integration Procedure Action) cannot directly invoke multiple OmniScripts in a user-facing context. Actions are components within an OmniScript or FlexCard, not standalone tools for orchestrating entire processes. This option also lacks a user interface for displaying contact data and initiating verification processes, making it incomplete for the requirement.

Recommended Solution

Create three FlexCards, one for each Contact record type (Recruiter, Candidate, Trainer), to display relevant contact data and verification status. Use DataRaptor Extract Actions or Integration Procedure Actions within the FlexCards to fetch record-type-specific data from Salesforce. Include Action elements on each FlexCard to invoke tailored OmniScripts for the verification processes:

Recruiter FlexCard → OmniScript for background check process.
Trainer FlexCard → OmniScript for mandatory training classes.
Candidate FlexCard → OmniScript for certification tracking.


Use Conditional Visibility or States in the FlexCards to ensure the correct card is displayed based on the Contact’s record type (e.g., using a formula or filter like RecordType.Name = 'Recruiter').
The OmniScripts can leverage Integration Procedures or DataRaptors to interact with Salesforce data (e.g., updating verification status) or external systems (e.g., background check APIs, training platforms).
This approach ensures a scalable, maintainable solution with a clear separation of concerns for each record type’s verification process, while providing an intuitive UI for users.

References

Salesforce Help: Create a Flexcard (Managed Package) – Explains how to configure FlexCards with Actions to invoke OmniScripts and display record-specific data.

Trailhead: OmniStudio FlexCards – Covers using FlexCards for contextual data display and triggering processes with Actions.

Salesforce Help: OmniScript Actions – Details how Actions in FlexCards can invoke OmniScripts for process automation.

Trailhead: Build an OmniScript – Describes designing OmniScripts for specific workflows, such as verification processes.

Explanation

This requirement describes a batch-oriented, server-side process, not a real-time user interaction. Let's break down the steps and map them to the correct tools.

"retrieve all open cases that have a case type of 'network issue'"

This is a bulk data extraction. We need to query potentially many records from Salesforce based on specific filter criteria (Status = 'Open' AND Type = 'Network Issue').

Correct Tool:A. DataRaptor Turbo Extract

Why: A DataRaptor Turbo Extract is specifically designed for high-performance, bulk data extraction from Salesforce. It can be configured with a filter to get exactly this dataset. It's the most efficient tool for this part of the job.

"submit the case data 'as-is' to a back-office system for validation"

This is an outbound integration. We need to take the data retrieved by the Turbo Extract and send it to an external system.

Correct Tool: D. Integration Procedure

Why: An Integration Procedure (IP) is the OmniStudio tool for orchestrating multi-step integrations. It can call the DataRaptor Turbo Extract to get the data, then use a step

to make an HTTP call out to the back-office system's API to submit the data. The IP acts as the controller for the entire batch process. "Once the cases have been submitted, the process should trigger an email to the supervisor."

This is a post-integration action. After the IP successfully sends the data to the back-office system, it needs to perform another action.

Correct Tool: E. DataRaptor Load

Why: A common and efficient way to send an email from an IP is to create a "Send Email" action in Salesforce (like an Email Alert) and then have the IP call a DataRaptor Load to execute it. The DataRaptor Load would be configured to trigger that specific email, using data from the IP (e.g., the supervisor's email address, a count of cases (submitted) to populate the email template.

How the Tools Work Together:

The recommended flow would be:

An automated scheduler (like a Scheduled Flow or Apex Scheduler) triggers the Integration Procedure daily.

The Integration Procedure executes a DataRaptor Turbo Extract to get all the relevant open cases.

The Integration Procedure then submits this batch of data to the back-office system via an HTTP Callout step.

Upon successful submission, the Integration Procedure calls a DataRaptor Load to trigger the email notification to the supervisor.

Why the Other Options Are Incorrect:

B. OmniScript: OmniScripts are designed for guided, interactive user experiences (like a UI in a console or a community). This requirement is for a fully automated, batch backend process with no user interface. An OmniScript is the wrong tool for this job.

C. FlexCard: FlexCards are for displaying data and enabling actions in a user interface. Like OmniScripts, they are user-facing components and are not used for automated, scheduled batch data processing.

Summary / Key Takeaway:

This solution leverages the core OmniStudio data and integration tools for a server-side batch process: Turbo Extract for bulk data retrieval, Integration Procedure for process orchestration and external communication, and DataRaptor Load for performing a post-action within Salesforce (sending an email).

Reference:

This pattern is covered in OmniStudio documentation and training materials related to batch data processing and Integration Procedures, specifically the use of Turbo Extract for bulk reads and DataRaptors for executing platform actions like sending emails.

Explanation

In OmniStudio (formerly Vlocity), when multiple versions of a Calculation Procedure are active and valid for the same effective date, the calculation engine uses the Priority value to determine which one to execute.

Validity Check: The engine first checks the Start Time and End Time fields for each version to ensure they are active for the current system date/time or the date provided in the input JSON.

Priority Check: If the engine finds more than one valid (active) version, it will execute the one with the highest Priority number.

This allows a company to manage different, simultaneously active pricing rules, where one specific rule (e.g., a special promotion) can override a general rule simply by assigning it a higher priority number.

Reference

This concept is standard across OmniStudio components that use versioning, such as Calculation Procedures and Calculation Matrices.

Salesforce OmniStudio Documentation (General Principle): When multiple versions are valid, the version with the highest Priority is run. (A higher number indicates a higher priority, where '1' is the lowest).

Explanation

The company requires a single LWC OmniScript to unify case creation processes across multiple customer support departments, with two key requirements: (1) capturing different case fields for each department and (2) redirecting users to the support console app if they cancel the process. The consultant should recommend the following OmniScript features:

Use Conditional Views on steps for each department (C):

Why it fits: OmniScript’s Conditional Views allow specific fields or elements within a step to be shown or hidden based on conditions, such as the department selected. For example, a picklist field (e.g., "Department") can be used to dynamically display relevant case fields (e.g., priority for one department, product type for another) within the same OmniScript. This ensures that each department’s unique field requirements are met without creating separate OmniScripts, maintaining a unified process. Conditional Views can be configured in the OmniScript Designer by setting conditions (e.g., Department = 'Sales' to show Sales-specific fields) on input elements like Text, Picklist, or Date.
How it works: In a single OmniScript, steps can include all possible case fields, with Conditional Views controlling which fields are visible based on a department selection or other criteria (e.g., a formula or data from a DataRaptor). This provides a tailored experience for each department while keeping the process centralized.

Add a Done action that redirects to the support console (D):

Why it fits: The Done Action in OmniScript defines what happens when the script is completed or canceled. To meet the requirement of returning to the support console app upon cancellation, the consultant can configure a Done Action with a Navigate Action (a type of OmniScript Action) to redirect the user to the support console app’s URL or Lightning App Page. In the OmniScript Designer, the Done Action can be set to trigger on cancellation (e.g., when the user clicks a "Cancel" button) and use a URL or Lightning Component navigation target (e.g., lightning/app/supportConsoleApp) to return the user to the console.
How it works: The Done Action can be configured in the OmniScript’s Setup tab, specifying a redirect to the support console app. This ensures a seamless user experience when the process is canceled, meeting the second requirement.

Why Other Options Are Incorrect:

A. Enable the Save for Later feature:

The Save for Later feature allows users to save their progress in an OmniScript and resume it later, storing data temporarily in Salesforce. While useful for long or multi-session processes, it does not address either of the stated requirements: capturing department-specific fields or redirecting to the support console upon cancellation. It’s irrelevant to the use case.

B. Set Enable Cancel in Setup:

The Enable Cancel option in OmniScript Setup allows a Cancel button to appear in the UI, letting users exit the script. While this enables cancellation, it does not specify where the user is redirected after canceling (e.g., to the support console app). Without a Done Action to handle the redirect, this option alone is insufficient to meet the second requirement. Additionally, it doesn’t address the need for department-specific fields.

How These Features Work Together:

Conditional Views are applied within OmniScript steps to dynamically show or hide case fields based on the department. For example, a Step might include a Block with fields like "Case Reason" for one department and "Product Code" for another, with visibility controlled by a condition like Department = 'Support' or Department = 'Billing'. A Done Action is configured in the OmniScript’s Setup to handle cancellation. When the user clicks Cancel, the Navigate Action redirects them to the support console app (e.g., using a URL like /lightning/app/c__SupportConsole or a Lightning App navigation target).
The OmniScript can be embedded as an LWC (Lightning Web Component) in a Lightning page or Experience Cloud site, ensuring compatibility with the support console app environment.

References

Salesforce Help: Conditional Views in OmniScript – Explains how to configure Conditional Views to show/hide elements based on data conditions, ideal for department-specific fields.

Trailhead: Build an OmniScript – Covers designing OmniScripts with Conditional Views for dynamic field display.

Salesforce Help: OmniScript Actions – Describes using Done Actions with Navigate Actions to redirect users to specific apps or pages.

Salesforce Help: Configure OmniScript Navigation – Details how to set up Done Actions for redirects, including to console apps.

Explanation

In a FlexCard, when multiple states have conditions that evaluate to true for a given record, the card needs a deterministic way to decide which single state to display. It does this by evaluating the states in a specific order.

The key factors are:

Order on the Canvas: States are evaluated from the top of the canvas to the bottom.

Condition is True: The card engine checks each state's condition in this top-down order.

First Match Wins: The first state it encounters (closest to the top) whose condition evaluates to true is the one that gets displayed. The conditions of states lower down on the canvas are not even evaluated once a match is found.

Why This is the Correct Answer:

The description in option C, "The first state with a true condition closest to the top of the canvas," perfectly captures this sequential, top-down evaluation logic. The card doesn't look at all states and then pick one; it starts at the top and stops at the first one that is valid.

Why the Other Options Are Incorrect:

A. The first state with the highest priority closest to the top of the canvas: This is incorrect because FlexCard states do not have a configurable "priority" property. The only inherent priority is their physical order on the canvas. The word "priority" is a distractor.

B. The state closest to the top of the canvas: This is incomplete and therefore misleading. The state at the very top will only be displayed if its condition is true. If the top state's condition is false, the card will move down the list until it finds a state with a true condition.

D. The state with a true condition that has the highest priority: As explained in A, there is no "highest priority" setting for states. This option invokes a non-existent feature.

Best Practice Implication:

This behavior is why a key best practice when designing FlexCards with multiple conditional states is to always have a default state with no condition at the very bottom of the list. This ensures that if none of the conditional states above it are true, there is a fallback state to display, preventing a blank card.

The evaluation flow looks like this:

Check State 1 (Top) Condition -> If true, display it. STOP.
If false, check State 2 Condition -> If true, display it. STOP.
If false, check State 3 Condition -> If true, display it. STOP.
... and so on ...
If all conditional states are false, display the final Default State (with no condition).

Summary / Key Takeaway:

FlexCard state selection is a simple, top-down, first-match-wins process. The visual order of states on the canvas is the single most important factor in determining which state is shown when multiple conditions are true.

Reference:

This behavior is explicitly defined in the Salesforce OmniStudio Documentation for FlexCards under the "Card States" section.

Explanation

The Select element in an OmniScript (which is part of OmniStudio) is the standard input component used to create a dropdown menu or picklist.

In its properties, the Select element has an Option Source setting that can be configured in one of three ways:

Manual: You manually enter the Label/Value pairs for the options.

Custom: You use an Apex class and method to dynamically generate the list of options.

SObject: This is the most direct way to retrieve values from a Salesforce picklist. You specify the Salesforce Object API Name and the Field API Name in the format ObjectAPIName.FieldAPIName (e.g., Account.Industry). The OmniScript engine automatically fetches the active picklist values for that field.

Reference

OmniScript Select Element: This element is specifically designed to work as a dropdown (or picklist) in the guided process. The "SObject" option source makes it a declarative tool for integrating with native Salesforce picklists.

Explanation

The requirement involves multiple business processes within OmniScripts that need to update contact data at various points. The solution must be efficient, reusable, and seamlessly integrated into these processes.

Let’s evaluate the options:

Create an Integration Procedure to update contact data with "Chain OnStep" enabled and invoke it from all OmniScripts (A):

Why it fits: An Integration Procedure is a reusable OmniStudio tool designed to handle complex data operations, such as updating contact data in Salesforce or external systems. By enabling the Chain OnStep property, the Integration Procedure can execute automatically at specific points (steps) within an OmniScript without requiring user interaction, making it ideal for updating contact data at various stages of multiple processes. This procedure can include DataRaptor Post Actions or REST/SOAP calls to update contact records efficiently. The Integration Procedure can be invoked by multiple OmniScripts using an Integration Procedure Action, ensuring a centralized, reusable solution that minimizes redundancy and maintenance overhead.

How it works: The consultant creates a single Integration Procedure to handle contact data updates (e.g., updating fields like Phone, Email, or Status). The "Chain OnStep" property allows the procedure to run automatically when a step is completed in any OmniScript, ensuring seamless updates at the required points. Each OmniScript can call this procedure via an Integration Procedure Action, passing relevant data (e.g., Contact ID, updated fields) as input.

Why it’s efficient:This approach avoids duplicating update logic across OmniScripts, supports scalability, and allows centralized management of the update process, which can also integrate with external systems if needed.

Create an OmniScript that uses the reusable property to update contact data and embed it in other OmniScripts (B):

Why it’s incorrect: While OmniScripts can be marked as reusable (via the "Reusable" property) and embedded as child OmniScripts within other OmniScripts, this approach is less efficient for updating contact data. OmniScripts are primarily designed for user-facing, guided processes with interactive UI elements, not for backend data updates. Embedding an OmniScript for each update operation would add unnecessary complexity and UI overhead, especially since the requirement focuses on data updates, not user interaction. Additionally, managing multiple embedded OmniScripts increases maintenance effort compared to a single Integration Procedure.

Create an OmniScript to update contact data and invoke it when other OmniScripts complete (C):

Why it’s incorrect: Creating a separate OmniScript to update contact data and invoking it at the completion of other OmniScripts is inefficient and restrictive. This approach assumes updates only occur at the end of a process, whereas the requirement specifies updates at “different points” in the process. An OmniScript is also UI-focused, which is unnecessary for a backend update task. Using an Integration Procedure with Chain OnStep is more flexible, as it can trigger updates at any step, not just at completion.

Create a FlexCard for contacts, and add an Update Contact Details OmniScript as an action (D):

Why it’s incorrect: FlexCards are designed for displaying data and providing actionable interfaces, not for executing backend data updates across multiple processes. While a FlexCard could display contact data and trigger an OmniScript to update details, this approach doesn’t address the need to update contact data at various points in multiple OmniScript processes. It’s also UI-centric, requiring user interaction to initiate updates, which may not align with the requirement for seamless updates during processes. Additionally, embedding an OmniScript as a FlexCard action doesn’t scale well for multiple OmniScripts needing the same update logic.

Recommended Solution

Create a single Integration Procedure to handle contact data updates, using DataRaptor Post Actions to update Salesforce Contact records or Integration Procedure Actions for external systems if needed. Enable the Chain OnStep property in the Integration Procedure to allow automatic execution at specific steps within OmniScripts, ensuring updates occur at the required points. In each OmniScript, add an Integration Procedure Action to invoke the contact update procedure, passing necessary data (e.g., Contact ID, field values) as inputs. This solution ensures reusability, minimizes duplication, and supports updates at any point in the process, aligning with the requirement for efficiency across multiple business processes.

References

Salesforce Help: Integration Procedures – Describes how Integration Procedures can aggregate and process data updates, with Chain OnStep for automatic execution.

Trailhead: OmniStudio Integration Procedures – Explains configuring Integration Procedures for reusable data operations, including updates across multiple OmniScripts.

Salesforce Help: Chain OnStep in Integration Procedures – Details how Chain OnStep enables automatic execution at specific OmniScript steps.

Salesforce Help: OmniScript Actions – Covers using Integration Procedure Actions to call reusable data operations within OmniScripts.