Free OmniStudio-Consultant Practice Test Questions (2026)

Explanation

The requirement has two distinct parts, and we need to identify the FlexCard features that address each one directly.

"A pop-up window will display additional information about the campaign, such as details about the members."

This describes a Flyout. A Flyout is a panel that slides out or pops up to display additional information that isn't visible on the main card.

Correct Feature: E. Flyout Action

Why: You would configure an element (like a button or a link labeled "View Members") with a Flyout Action. When the user clicks it, the flyout opens. Inside this flyout, you could use a Data Table (Option D) to neatly display the list of campaign members, but the action that triggers the pop-up window itself is the Flyout Action.

"A button must initiate a guided process to add new leads to the campaign."

This describes launching an OmniScript. A "guided process" is the textbook definition of an OmniScript.

Correct Feature: B. OmniScript Action

Why: You would add a button to the FlexCard and configure its action as an OmniScript Action. This action would be set to launch a specific OmniScript (the one designed for adding leads to a campaign). This provides the step-by-step, form-based experience implied by "guided process."

How the Features Work Together: The consultant would likely design the FlexCard to have:

A "View Members" button with a Flyout Action that opens a panel containing a Data Table of existing members.

A separate "Add Leads" button with an OmniScript Action that opens the guided process in a modal window or a new tab.

Why the Other Options Are Incorrect:

A. Block Element: A Block Element is a container for organizing the layout within a card or flyout. It is not an action that triggers a pop-up or launches a process. It's a structural component, not a functional one for this use case.

C. Interaction Launcher: This is a distractor. While it sounds relevant, "Interaction Launcher" is not a standard, named feature within the FlexCard toolbox. The specific actions you configure are "OmniScript Action," "Flyout Action," "URL Action," etc.

D. Data Table: A Data Table is a display element used to show a list of records in a tabular format. It is what you would put inside the flyout to show the member details, but it is not the feature that creates the pop-up window. The action that creates the pop-up is the Flyout Action.

Summary / Key Takeaway:

To meet both requirements, you need two different types of Actions on your FlexCard:
A Flyout Action to create the pop-up for displaying information.
An OmniScript Action to launch the guided process for adding records.

Reference:

The configuration of these actions is a fundamental part of building interactive FlexCards and is covered in the "Add Actions to FlexCards" unit of the OmniStudio Trailmix on Trailhead.

Explanation

In OmniStudio, the structure and user experience are paramount. The Step element is a fundamental building block that serves a specific organizational purpose.

What a Step Is: A Step is a container that represents a single "page" or "screen" in the OmniScript's guided flow. It groups other elements (like input fields, text, and selectors) together to be displayed at the same time.

How It Works: When an OmniScript runs, the user progresses through one Step at a time. Each Step is typically focused on collecting a related set of information or performing a specific action. For example, you might have a "Personal Details" step, followed by a "Billing Information" step, and then a "Review" step.

Why This is the Correct Answer:

Option D directly and accurately describes this primary function. Steps break down a potentially long and complex process into manageable, logical chunks for the user, organizing the overall script into a multi-page experience.

Why the Other Options Are Incorrect:

A. Allows the user to input data: This is the purpose of individual elements within a Step, such as Text, Number, Select, or Checkbox elements. The Step itself is just the container; it doesn't directly capture data.

B. Groups elements that extract data: This describes the function of a DataRaptor Turbo Extract or a step within an Integration Procedure. In an OmniScript, Steps are for user interaction, not for backend data extraction.

C. Enables the use of repeatable blocks: This is the function of the **Edit Block element. An Edit Block allows users to add, modify, and remove multiple records of the same type within a single step (e.g., adding multiple dependents to an insurance policy). This is different from the high-level page organization provided by Steps.

Summary / Key Takeaway:

Think of Steps as the "pages" in a wizard and the elements inside them (Text, Select, etc.) as the "questions on each page." The Step's core job is to provide structure and pagination to the user journey.

Reference:

This is a foundational concept covered in the "Get to Know OmniScript" module on Trailhead, which explains that "Steps break down the script into multiple pages."

Explanation

The requirement involves two distinct steps:

Looking up a value (Unit Price) based on multiple input variables (Product Code, Grade, Size).

Performing calculations (multiplying the Unit Price by a Discount Factor).

The two recommended OmniStudio tools address these steps:

1. Calculation Matrix (A)

The Calculation Matrix is the ideal tool for performing lookups based on multiple input variables (Product Code, Grade, Size). It uses a two-dimensional grid structure (like a spreadsheet) where you define:

Input columns: Used to match the incoming data (Product Code, Grade, Size).

Output columns: Used to return the corresponding value (Unit Price).

Key Benefit: It provides a highly efficient, declarative way to store and retrieve large sets of conditional data without writing code or making complex SOQL queries.

2. Calculation Procedure (D)

The Calculation Procedure is the ideal tool for the second step: performing complex, multi-step calculations.

The Calculation Procedure can call the Calculation Matrix to retrieve the Unit Price.

Once the Unit Price is returned, the Calculation Procedure can then apply the business logic, such as:

Total Price=Unit Price×Discount Factor

It organizes the calculation flow, handles variables, and ensures all formulas are executed in the correct sequence.

Why the other options are incorrect:

B. DataRaptor Transform: This tool is for restructuring JSON data (e.g., changing node names), not for performing multi-criteria lookups or complex arithmetic calculations.

C. DataRaptor Extract: This tool is used to query data from Salesforce objects using SOQL. While it could theoretically retrieve a single price, it's not the best practice for complex multi-criteria pricing lookups, which is what the Calculation Matrix is designed for. It also cannot perform the final multiplication step.

Explanation

The business requires a 360° view of accounts with a FlexCard displaying all products sold, including 20 data elements and 10 actions. The resulting FlexCard appears cluttered due to the large number of elements and actions. The consultant needs to recommend a FlexCard feature to address the clutter while maintaining functionality.

Let’s evaluate the options:

Flyouts (D):

Why it fits: Flyouts in FlexCards are used to display additional details or actions in a pop-up or modal window when a user interacts with an element (e.g., clicking a product in a Data Table or Repeat Block). By moving some of the 20 data elements and 10 actions into Flyouts, the consultant can declutter the main FlexCard canvas. For example:

The main FlexCard could show a concise Data Table with key product fields (e.g., Product Name, Price, Quantity) and a "Details" button.

Clicking the button opens a Flyout displaying the remaining data elements (e.g., product specifications, purchase date) and actions (e.g., edit product, initiate return).

Flyouts keep the primary view clean and focused, presenting additional information and actions only when needed, improving user experience and addressing the clutter issue effectively.

How it works: In the FlexCard Designer, a Flyout is configured as an Action or Element property, triggered by user interaction (e.g., clicking a button or row). The Flyout can contain additional fields, child FlexCards, or actions, organized to present the 20 data elements and 10 actions in a structured, on-demand manner.

Zones (A):

Why it’s incorrect: Zones in FlexCards are layout containers used to organize elements into sections (e.g., header, body, footer) on the canvas. While Zones help structure the layout, they don’t inherently reduce clutter when dealing with a large number of data elements and actions. Adding 20 data elements and 10 actions within Zones would still overwhelm the UI, as Zones only group content, not hide or defer it like Flyouts.

States (B):

Why it’s incorrect: States in FlexCards control conditional visibility of elements based on data or business logic (e.g., showing different fields for active vs. inactive accounts). While States can hide irrelevant elements, they are not designed to manage clutter caused by a high volume of data elements and actions. Using States to toggle between subsets of the 20 elements or 10 actions would require complex logic and user interaction, making the UI less intuitive and not directly addressing the clutter issue.

Actions (C):

Why it’s incorrect: Actions in FlexCards (e.g., buttons or links to invoke OmniScripts, Integration Procedures, or navigations) are already part of the 10 actions required. Adding more Actions or relying solely on them doesn’t address the clutter caused by displaying 20 data elements and 10 actions simultaneously. Actions are functional triggers, not a layout or presentation solution for reducing visual overload.

Recommended Solution

Use Flyouts to offload secondary data elements and actions from the main FlexCard canvas. For example:

Display a Data Table or Repeat Block with 5-7 key product data elements (e.g., Product Name, SKU, Price) to keep the main view clean.

Add a button or link in each row/card to open a Flyout containing the remaining data elements (e.g., warranty details, serial number) and the 10 actions (e.g., edit, delete, or custom processes like initiating a refund).

Configure Flyouts in the FlexCard Designer to trigger on user interaction, ensuring the additional 13-15 data elements and 10 actions are accessible without cluttering the primary view.

Optionally, organize Flyout content using Zones within the Flyout for better structure, but Flyouts are the primary feature to address the clutter.

References

Salesforce Help: Add Flyouts to a FlexCard – Describes how Flyouts display additional data or actions in a pop-up to reduce clutter on the main FlexCard canvas.

Trailhead: Style FlexCard Elements – Explains how Flyouts can be used to manage complex data and actions in a user-friendly way.

Salesforce Help: Create a Flexcard (Managed Package) – Covers designing FlexCards with Flyouts to optimize UI for large datasets and actions.

Explanation

The core principle here is to prioritize the most frequent and important actions. While we don't have the exact exhibit, we can deduce the logic from the options and typical business scenarios:

Frequency: "Verify a transaction," "View statements," and "Make a payment" are high-frequency, day-to-day tasks for both customers and service agents. Customers frequently call about transaction discrepancies, need to see their statements, and make payments.

Importance: These actions are critical to the core business of account management.

Make a Payment (E): Directly impacts revenue and customer account health.

Verify a Transaction (A): Directly related to security, fraud prevention, and resolving common customer issues.

View Statements (D): A fundamental action for providing account history and resolving billing inquiries.

Why the Other Options Are Less Likely

B. Request higher limit: This is an important action but is typically a low-frequency event. A customer might request a credit limit increase a few times a year at most, not daily or weekly.

C. View credit score history: Similar to a limit increase, this is a valuable feature but is not a high-frequency action for a typical agent handling common account inquiries. It's more of a periodic check.

Exam Strategy & Reference

Key Concept: This question tests the Salesforce UX Design principle of "Relevancy" and "Efficiency." A FlexCard, much like a Lightning Page, should be tailored to the user's persona and their most common tasks to save time and clicks.

How to Approach: In the exam, the "user analysis exhibit" would likely be a table or chart showing metrics like "Number of Times Action Performed Per Day" or "User Priority Ranking." You would simply select the three actions with the highest numbers.

Reference:

While not a direct link to documentation, this logic is embedded in the Salesforce Platform App Builder and User Experience Designer certification guides, which emphasize building context-aware and efficient interfaces. For the Email Specialist, it shows an understanding of how data drives decision-making in the Salesforce ecosystem.

In summary, the card should be designed for the most common and critical scenarios to maximize agent efficiency, which points to A, D, and E.

Explanation

The requirements map directly to these three OmniScript elements, which handle the user interface, external integration, and data saving respectively.

1. Multi-select Input (B) ➡️ User Selection

Requirement Met: "Allow the user to select one or more energy products from a list."

The Multi-select Input element is the standard OmniScript component designed to allow a user to choose multiple values from a list (e.g., Checkboxes or a Multi-select Picklist), fulfilling the requirement to select "one or more" products.

2. HTTP Action (E) ➡️ External Data Retrieval

Requirement Met: "Get current energy usage data from an external system via an API."

The HTTP Action is the element used in OmniScript (or an Integration Procedure it calls) to make an outbound call to a third-party REST API endpoint, which is necessary to retrieve the external energy usage data.

3. DataRaptor Post Action (A) ➡️ Save Data to Salesforce

Requirement Met: "Save the data back to Salesforce as a lead."

The DataRaptor Post Action is the standard OmniStudio element used to write, update, or upsert data into Salesforce objects (in this case, creating a new Lead record) based on the JSON data collected during the OmniScript process.

Why the other options are incorrect:

C. Post to Object Action: This action is a simpler element that only supports writing data to a single Salesforce object. While it could create the Lead, the DataRaptor Post Action is more flexible, allowing complex data mapping and manipulation, making it the generally recommended and scalable approach in most OmniScript processes.

D. Radio Input: This is an input element, but it is used when a user can select only one option from a list, not "one or more." The Multi-select Input (B) is required to meet the specific "one or more" criterion.

Explanation

The health provider company needs to display medical test reports (a custom object related to the Patients object) for each patient, showing fields like report name, date requested, and date generated, with the ability to perform three actions (Approve, Print for Review, Send for Retest) per report. OmniStudio tools, such as FlexCards and OmniScripts, are well-suited for creating a modern, user-friendly interface with actionable functionality.

Let’s evaluate the options:

Single FlexCard with multiple actions (D):

Why it fits: A FlexCard is ideal for displaying data in a concise, customizable format, such as a list of medical test reports for a patient. The FlexCard can use a Data Table or Repeat Block to dynamically display the required fields (report name, date requested, date generated) for each medical test report, retrieved via a DataRaptor Extract Action querying the Medical Test Report custom object related to the Patient record. The FlexCard can include multiple Actions (e.g., buttons or links) for each report to trigger the required actions:

Approve: An Action invoking an OmniScript or Integration Procedure to update the report’s status (e.g., set a Status field to "Approved").

Print for Review: An Action triggering a process to generate a printable report, possibly via an OmniScript or Integration Procedure that formats data for printing.

Send for Retest: An Action invoking an OmniScript or Integration Procedure to initiate a retest request, potentially updating fields or creating a new record.

The FlexCard can be embedded in a Lightning page or Experience Cloud site, providing a 360° view of the patient’s reports with actionable buttons for medical officers. This solution is efficient, scalable, and aligns with OmniStudio’s declarative design capabilities, meeting all requirements in a single, cohesive interface.

How it works: In the FlexCard Designer, configure a Data Table or Repeat Block to display medical test report records, with a DataRaptor Extract to fetch data (e.g., SELECT Name, Date_Requested__c, Date_Generated__c FROM Medical_Test_Report__c WHERE Patient__c = :patientId). Add Action elements (e.g., buttons) for Approve, Print for Review, and Send for Retest, each linked to an OmniScript or Integration Procedure for processing.

Salesforce list view with custom buttons/links (A):

Why it’s incorrect: While a Salesforce list view can display medical test reports with custom buttons or links (created via Lightning App Builder or custom code), it is not an OmniStudio tool and lacks the advanced customization and integration capabilities of FlexCards. List views are limited to standard Salesforce UI patterns and don’t support complex, guided processes or external system integrations as seamlessly as OmniStudio. Additionally, custom buttons/links may require more custom code (e.g., Apex, Visualforce) to implement actions like Print for Review or Send for Retest, making it less efficient than a declarative OmniStudio solution.

Multiple FlexCards with single action (B):

Why it’s incorrect: Creating multiple FlexCards, each with a single action, is inefficient and unnecessary. A single FlexCard can handle multiple actions per record (Approve, Print for Review, Send for Retest) using a Data Table or Repeat Block. Multiple FlexCards would lead to redundant configurations, increased maintenance, and a fragmented user experience, as users would need to navigate multiple cards for the same patient’s reports. This approach doesn’t align with the requirement for a unified view of all reports with multiple actions.

OmniScript with multiple Step elements (C):

Why it’s incorrect: OmniScripts are designed for guided, interactive processes (e.g., wizards for data entry or updates), not for displaying lists of records with actions. While an OmniScript could be used to handle the actions (e.g., Approve, Print, Retest), it’s not suited for displaying a dynamic list of medical test reports in a tabular or card-based format. Using multiple Step elements to list reports would be cumbersome and non-intuitive, as OmniScripts are sequential and process-oriented, not optimized for data presentation like FlexCards.

Recommended Solution

Create a single FlexCard to display medical test reports for a patient, using a Data Table or Repeat Block to list records with fields: report name, date requested, and date generated.

Configure a DataRaptor Extract Action to fetch Medical Test Report records related to the Patient (e.g., SELECT Name, Date_Requested__c, Date_Generated__c FROM Medical_Test_Report__c WHERE Patient__c = :patientId).

Add multiple Actions to the Data Table or Repeat Block:

Approve: Triggers an OmniScript or Integration Procedure to update the report’s status (e.g., Status__c = 'Approved'). Print for Review: Invokes an OmniScript or Integration Procedure to generate a printable report, potentially using a DataRaptor Transform to format data or a REST API to a printing service.

Send for Retest: Launches an OmniScript or Integration Procedure to create a retest request, updating fields or creating a new record (e.g., Retest_Requested__c = true or a new Medical Test Report record).

Embed the FlexCard in a Lightning page or Experience Cloud site for medical officers to access within the application.

Optionally, use Conditional Visibility or States to filter reports (e.g., show only pending reports) or style the UI based on report status. This solution leverages FlexCards’ strengths for data display and actionability, ensuring a clean, efficient interface that meets all requirements.

References

Salesforce Help: Create a Flexcard (Managed Package) – Explains configuring FlexCards with Data Tables or Repeat Blocks to display related records and add multiple actions.

Trailhead: OmniStudio FlexCards – Covers using FlexCards for data presentation and triggering actions like OmniScripts or Integration Procedures.

Salesforce Help: Add Actions to a FlexCard – Details how to configure multiple actions (e.g., buttons) to invoke processes for tasks like approving or printing.

Salesforce Help: Omnistudio Data Mapper Extract Action (Managed Package) – Describes retrieving related records (e.g., Medical Test Reports) for display in a FlexCard.

Explanation

An Integration Procedure is a powerful OmniStudio tool that orchestrates complex business logic and data interactions. It's not just a simple data call; it's a multi-step process.

Why B is Correct: To retrieve multiple data sources in a single response

A primary strength of an IP is its ability to call multiple external systems (e.g., Salesforce core, an external billing system, a payment gateway, a legacy database) within a single, orchestrated procedure. It can take the output from one step (e.g., get account details from Salesforce) and use it as input for the next step (e.g., get billing summary from an external system), and then combine, transform, and return a unified JSON response to the FlexCard or OmniScript.

Benefit: This saves you from having to configure multiple, separate DataRaptors or external sources directly in your FlexCard/OmniScript, simplifying the front-end configuration and improving performance by reducing round trips.

Why D is Correct: To separate the user interface from changes in the data sources

This is a fundamental principle of good software architecture: separation of concerns. By using an IP as an abstraction layer, the FlexCard or OmniScript (the "UI") only needs to know about the IP's interface (the input it expects and the output it returns).

Benefit: If the backend data source changes (e.g., you switch from one API to another, or a field is renamed in the source system), you only need to update the logic within the Integration Procedure. The FlexCard or OmniScript that consumes the IP's response remains completely untouched. This makes your solution far more maintainable and resilient to change.

Why the Other Options Are Incorrect

A. To achieve elastic scaling

Elastic scaling is a characteristic of the underlying cloud infrastructure (like Salesforce Heroku or AWS), not a feature provided by the Integration Procedure logic itself. While a well-architected IP contributes to efficient resource use, the "elastic scaling" is handled by the platform, not the IP code.

C. To minimize the number of elements to be configured

This is the opposite of the typical outcome. Using an IP often increases the total number of elements you need to configure. You must build the IP itself (with its steps, inputs, and outputs) in addition to the DataRaptors or other elements it uses. While it simplifies the front-end (FlexCard/OmniScript) configuration, it adds complexity to the back-end configuration. The goal is power, reusability, and maintainability, not necessarily minimization of elements.

Exam Strategy & Reference

Key Concept: This tests your understanding of the role of an Integration Procedure as an orchestration and abstraction layer.

Reference:

The official Salesforce OmniStudio Developer Guide emphasizes that Integration Procedures are used for multi-system orchestration and complex business logic. The best practice of using a "headless" design (separating business logic in IPs from the UI in OmniScripts/FlexCards) directly supports answer D.

In summary, you use an Integration Procedure when you need to orchestrate complex data from multiple sources (B) and to create a maintainable abstraction between your UI and your backend systems (D).

Explanation

The Calculation Procedure/Matrix Simulator is an essential development and testing tool within OmniStudio. The primary benefit for developers is its ability to test logic without needing to integrate the calculation into a full OmniScript or Integration Procedure.

What-If Testing: The simulator lets developers quickly enter various combinations of input values (e.g., different product codes, grades, and sizes) and instantly see the corresponding output results (e.g., the calculated unit price and final total). This iterative process is crucial for confirming that the pricing and discount logic is working correctly across all possible business scenarios, which is the definition of "what-if" calculations.

Debug and Validation: It is the primary tool for debugging by showing the results of each step within the procedure, allowing developers to isolate where a formula or matrix lookup might be failing.

Why the other options are incorrect:

A. It aggregates data elements that have been calculated separately: While the Calculation Procedure does aggregate data (by combining matrix lookups and formulas), the simulator's benefit isn't the aggregation itself, but the ability to test it.

B. It verifies data types...: The simulator will throw an error if data types are incompatible, but its main benefit isn't simply type checking; it's the ability to test complex logic.

C. It generates sample input and output JSON...: The simulator uses JSON for input and output, but it doesn't generate sample JSON for use in DataRaptors. Developers typically build the JSON input manually or by copying from a related Integration Procedure test to use the simulator effectively.

Explanation

The business needs an OmniScript to improve customer satisfaction by allowing customers to rate their satisfaction (1-5 scale) and, if the rating is less than 2, request a callback on a specific date and create a case with a list of bills from an external system for the last 5 months in the case description. The OmniScript elements must be arranged in a logical order to achieve this flow.

Let’s break down the requirements and evaluate the correct order:

Requirements and Element Mapping

Customer rates satisfaction (1-5 scale):

Use a Radio Input element to present a 1-5 rating scale, allowing the customer to select their satisfaction level. This element is ideal for single-choice selections with predefined options.

If satisfaction is less than 2, allow callback request:

Use a Date Input element to let the customer select a callback date. This element should be conditionally displayed based on the Radio Input value (e.g., satisfaction < 2) using Conditional View settings.

Retrieve list of bills from external system (last 5 months):

Use an HTTP Action to call an external system’s API (e.g., REST or SOAP) to fetch billing data for the last 5 months. This action retrieves the bill list to include in the case description.

Create a case with bill list in description:

Use a DataRaptor Post Action to create a Case record in Salesforce, populating the description with the bill list retrieved from the HTTP Action.

Correct Order: A. Radio Input, Date Input, HTTP Action, DataRaptor Post Action

Step 1: Radio Input:

The OmniScript starts with the Radio Input element to capture the customer’s satisfaction rating (1-5). This is the first interaction, as the subsequent steps depend on the rating value. The Radio Input can be configured with options (1, 2, 3, 4, 5) and stores the selected value for conditional logic.
Example: In the OmniScript Designer, create a Radio Input element with values 1-5, labeled “Rate your satisfaction.”

Step 2: Date Input:

If the satisfaction rating is less than 2, the Date Input element is displayed to allow the customer to select a callback date. This element uses Conditional View logic (e.g., Satisfaction_Rating < 2) to show only when the condition is met. This step follows the Radio Input because the rating determines whether the callback request is needed.
Example: Configure a Date Input element with a label like “Select Callback Date” and a condition to display if Satisfaction_Rating < 2.

Step 3: HTTP Action:

After capturing the rating and callback date (if applicable), the HTTP Action retrieves the list of bills from the external system for the last 5 months. This action requires customer context (e.g., Customer ID) and may use a date range filter (e.g., last 5 months). It follows the Date Input because the bill list is needed for the case creation, and the OmniScript flow should collect all user inputs before making external calls.
Example: Configure an HTTP Action to call a REST API (e.g., GET /bills?customerId={customerId}&startDate={5_months_ago}) to fetch the bill list, storing the response in a JSON node.

Step 4: DataRaptor Post Action:

Finally, the DataRaptor Post Action creates a Case record in Salesforce, including the bill list from the HTTP Action in the case description. If the satisfaction rating was less than 2, it also includes the callback date. This action is last because it depends on the data collected from the Radio Input (rating), Date Input (callback date), and HTTP Action (bill list).
Example: Configure a DataRaptor Post Action to create a Case with fields like Subject = "Low Satisfaction Follow-Up", Description = "Bills: {bill_list_from_HTTP}", and Callback_Date__c = {date_from_Date_Input}`.

Why Other Options Are Incorrect

B. Date Input, Radio Input, HTTP Action, DataRaptor Post Action:

Incorrect because the Date Input (callback date) should only appear if the satisfaction rating is less than 2, which requires the Radio Input to come first. Placing Date Input before Radio Input disrupts the conditional logic and user flow, as the rating hasn’t been captured yet.

C. HTTP Action, DataRaptor Post Action, Date Input, Radio Input:

Incorrect because starting with the HTTP Action to fetch bills is premature, as the satisfaction rating (Radio Input) and callback date (Date Input) are needed first to determine whether a case should be created. Similarly, creating the case (DataRaptor Post Action) before collecting user inputs (Date Input, Radio Input) is illogical, as the case depends on those inputs.

D. HTTP Action, Radio Input, Date Input, DataRaptor Post Action:

Incorrect because the HTTP Action (fetching bills) should occur after the user inputs (Radio Input for rating, Date Input for callback) are collected. Fetching external data before knowing whether the rating is less than 2 is inefficient, as the bill list is only needed for case creation in that scenario.

Why Option A Is Efficient

Logical Flow: The order follows the user journey: capture satisfaction rating (Radio Input), conditionally collect callback date (Date Input), fetch external bill data (HTTP Action), and create the case (DataRaptor Post Action).

Conditional Logic: The Radio Input’s value controls whether the Date Input is shown, ensuring the callback request only appears for ratings < 2.

Data Dependency: The HTTP Action and DataRaptor Post Action rely on prior inputs (rating, callback date, customer context) to fetch and save the correct data.

Declarative Design: This sequence leverages OmniStudio’s declarative tools to create a seamless, guided process without requiring custom code.

Additional Notes

Conditional View: In the OmniScript Designer, set a Conditional View on the Date Input element (e.g., Satisfaction_Rating < 2) to ensure it only displays when needed.

Data Integration: The HTTP Action may require an Integration Procedure to format the bill list or handle complex API calls, but the HTTP Action itself is sufficient for a single REST/SOAP call.

Case Creation: The DataRaptor Post Action maps the bill list (from HTTP Action) and callback date (from Date Input) to the Case record’s fields, ensuring all required data is included.

References

Salesforce Help: OmniScript Element Types – Describes Radio Input for rating scales and Date Input for date selection.

Salesforce Help: Conditional Views in OmniScript – Explains how to use Conditional Views to show elements like Date Input based on conditions (e.g., rating < 2).

Trailhead: OmniStudio Integration Procedures – Covers HTTP Action for external system calls, such as fetching bills.

Salesforce Help: Omnistudio Data Mapper Post Action (Managed Package) – Details creating records (e.g., Case) with data from prior OmniScript elements.