Explanation

A FlexCard can display data and provide actions, but those actions must be handled using the correct OmniStudio mechanisms.

To implement the required actions:

Start a process to retrieve plan consumption data → This can be triggered using an Event within the FlexCard (e.g., launching an Integration Procedure or OmniScript in the background).

Create a new case → Also initiated via an Event, which could launch an OmniScript, an Integration Procedure, or Salesforce standard action.

Open a promotions web page → This is handled using Navigate to redirect the user to an external or internal URL.

Change the SIM card → Likely triggers either another Event or opens a sub-Card or embedded OmniScript — hence Card is included as part of the solution.

The only option that includes all required types — Event (for backend or guided actions), Navigate (for URL redirect), and Card (to encapsulate UI logic or show child components) — is:

C. Event, Navigate and Card

Why the Others Are Not Ideal

A. Custom Event and Redirect URL → Too limited; doesn’t account for launching internal processes or embedding child cards.

B. OmniScript and Navigate → Navigate works, but OmniScript alone won’t handle all actions (especially lightweight ones like opening links or launching backend processes directly).

D. Flyout and OmniScript → Flyout is for displaying additional content temporarily, not for launching multiple different functional actions.

Explanation:

Action elements in OmniScript are used to execute backend processes, such as:

Integrating with APIs (B) – Fetching or sending data to external systems.
Sending DocuSign emails (D) – Automating e-signature workflows.
CRUD operations in Salesforce (E) – Querying, inserting, or updating records.

Why the Others Are Incorrect:

A (Display errors) → Handled by Set Errors, not an Action.
C (Organize pages) → Managed by Step elements, not Actions.

Reference:
Salesforce Docs: OmniStudio Actions.

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.

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.

Explanation:

A DataRaptor Extract is designed to pull data from Salesforce. It can:
➡️ Query one object.
➡️ Query multiple related objects using relationships (like Account → Contacts).
➡️ Return the data in JSON format for use in FlexCards, OmniScripts, or Integration Procedures.

Why the other options are wrong:

A. Create data in multiple related objects
That’s a job for DataRaptor Load, not Extract. Extract only retrieves data.

B. Extract data from a spreadsheet
DataRaptors work with Salesforce objects (and sometimes external sources via Integration Procedures), not spreadsheets.

D. Load data from external sources
That’s also not correct. Integration Procedures handle external APIs. DataRaptor Extract is Salesforce-only.

✅ Exam Tip:
⇒ Extract = get data out of Salesforce
⇒ Load = write data into Salesforce
⇒ Transform = reshape/format data
⇒ Turbo Extract = faster, simple retrieval (1 object, no joins)