Explanation:

This question tests your understanding of implementing conditional navigation in an OmniScript. When the user path depends on values already available in the OmniScript, the recommended approach is to use client-side visibility rules instead of invoking server-side logic.

🟢 Correct Option:

C. The Conditional View property on the Step elements:
The Conditional View property allows each OmniScript Step to be shown or hidden based on conditions evaluated against the OmniScript's data JSON. Since the customer type is selected on the first screen, subsequent steps can be displayed conditionally without using server-side processing, making this the most efficient and recommended solution.

🔴 Incorrect Options:

A. The Pub/Sub property on the FlexCard elements:
The Pub/Sub feature enables communication between FlexCards and other components by publishing and subscribing to events. It is not intended to control the visibility or navigation of OmniScript steps based on user input, so it does not satisfy the requirement.

B. An Integration Procedure's conditional block:
An Integration Procedure can evaluate conditions while processing server-side logic, but the requirement explicitly prohibits using server-side processing to control the user path. Conditional View provides the required client-side behavior directly within the OmniScript.

D. A Data Mapper's requirement mapping:
A Data Mapper is used to extract, transform, or load data between systems. It does not control the visibility of OmniScript steps or implement conditional navigation based on user selections. Therefore, it is not suitable for this scenario.

🔧 Reference:
⇒ Salesforce Help – OmniScript Conditional View
Explains how the Conditional View property controls the visibility of OmniScript elements and steps using client-side conditions based on the data JSON.

Explanation

This question tests understanding of how to validate a performance assumption before building out a full solution. Since the team is assuming a Data Mapper query will be performant, the developer's first step should be to confirm the query itself is optimized, since query efficiency directly determines whether the prefill requirement can be met.

✅ Correct Option

A. Verify indexed fields and query efficiency
Before relying on a Data Mapper to prefill 15 fields, the developer should confirm that the fields being queried are indexed and that the underlying query is efficient, since unindexed lookups on high-volume objects like User can slow performance significantly. This validation step directly tests the team's assumption and identifies risk before further development, aligning with OmniStudio best practices for Data Mapper design.

❌ Incorrect Options

B. Data Mapper Load to write user data back
Writing data back to the User object addresses saving data, not retrieving it for prefill purposes. This action doesn't test or validate the read performance of the query being used to populate the 15 fields, so it doesn't address the stated risk.

C. Convert the OmniScript to a FlexCard
Switching component types doesn't resolve the underlying question of whether the Data Mapper query itself is efficient. A FlexCard would face the same query performance concerns if it used the same unoptimized Data Mapper, making this an unrelated and premature change.

D. Use a Formula element instead of a Data Mapper
A Formula element performs client-side calculations, not server-side data retrieval from Salesforce records. It cannot replace a Data Mapper's function of pulling the logged-in user's stored field values, so it doesn't validate or fix the described performance concern.

Reference:
→ Salesforce Help – DataRaptor and Data Mapper Best Practices — confirms ensuring queried fields are indexed and filtered efficiently is essential for maintaining performant data retrieval in OmniStudio.

Explanation:

This question tests your knowledge of how OmniStudio handles asynchronous execution patterns within an OmniScript.

✅ Correct Option:

C. Invoke Mode Fire and Forget
When you configure an Integration Procedure Action, the Invoke Mode property determines how the UI waits for the server response. Setting the mode to Fire and Forget triggers the Integration Procedure on the server but does not block the user's progress. The OmniScript immediately proceeds to the next step or action without waiting for the server-side process to finish. This is ideal for background tasks (like sending a confirmation email or updating a log) where the user does not need to see the immediate result of the execution.

❌ Incorrect options:

A. Use Future
"Use Future" is not a standard configuration property for an Integration Procedure Action in OmniScript. While Apex has `@future` methods for asynchronous processing, it is not a UI-level toggle in the OmniScript designer.

B. Invoke Mode Non-Blocking
There is no "Non-Blocking" invoke mode in standard OmniStudio. This is a common distracter term.

D. Toast Completion
Toast messages are UI notifications used to display success or error feedback to the user after an action completes; they are not an execution mode for controlling how the Integration Procedure is triggered or how the script waits for it.

🔧 Reference:
→ Salesforce Help: Integration Procedure Action Properties - Defines the available invocation modes (Blocking vs. Fire and Forget) for background server-side execution.

Explanation:

This question tests your understanding of which OmniStudio component is best for presenting data from multiple sources in a unified interface. When users need to view related information directly on a Salesforce record page without navigating elsewhere, FlexCards provide a concise and reusable display solution.

🟢 Correct Option:

D. FlexCard:
A FlexCard is designed to display information from Salesforce and external systems in a single, focused view. By using an Integration Procedure or other supported data source, it can retrieve and combine pending service requests from multiple systems and present them directly on the Contact record page without requiring users to leave the current context.

🔴 Incorrect Options:

A. Data Mapper Transform:
A Data Mapper Transform restructures or converts data between JSON formats. Although it can prepare data for display, it does not provide a user interface. Another OmniStudio component, such as a FlexCard, is still required to present the combined information to the case manager.

B. Calculation Procedure:
A Calculation Procedure performs pricing, scoring, or other business calculations based on configured rules. It is not intended to retrieve and display data from multiple systems on a Salesforce record page, making it unsuitable for this requirement.

C. OmniScript:
An OmniScript is intended for guided user interactions and multi-step business processes. The requirement is simply to display combined information in a consistent view on the Contact record page, not to guide users through a workflow. A FlexCard is the more appropriate solution.

🔧 Reference:
⇒ Salesforce Help – FlexCards
Explains how FlexCards display data from Salesforce and external sources in a focused, reusable interface on Lightning record pages.

Explanation:

This question tests the knowledge of tools used for migrating OmniStudio components. The Salesforce Command-Line Interface (SFCLI) is the standard tool for managing and migrating Salesforce metadata, including OmniStudio components, between development environments and source control .

✔️ Correct Option:

Option D:
The Salesforce Command-Line Interface (SFCLI) provides commands for metadata deployment and retrieval that work with OmniStudio components. Through the SFCLI, developers can use the mdapi commands or the new source commands to migrate components like Data Mappers, FlexCards, and Integration Procedures between orgs and to source control .

❌ Incorrect options:

Option A:
Visual Studio Code Integrated Terminal is an execution environment, not a migration tool. While you can run SFCLI commands from it, the terminal itself is not the migration interface .

Option B:
The Metadata API is the underlying protocol for migration but is not a command-line interface. It's a SOAP-based API that SFCLI uses but is not a CLI tool itself .

Option C:
Change Data Capture (CDC) CLI is not a valid Salesforce tool. CDC is a data replication feature, not a migration interface for components .

🔧 Reference:
→ Salesforce Help: Migrate OmniStudio DataPacks with SFCLI - Explains using SFCLI for OmniStudio component migration.

→ Trailhead: Move DataPacks Between Orgs Using SFDX - Confirms SFCLI is the standard for migrating OmniStudio components.