Explanation:

This question tests your understanding of how to reference elements in the JSON structure generated by an Integration Procedure. When sending data from a nested element (like Action1) to another element (like a Remote Action), the Send JSON Path must use a colon-delimited path to specify the location of that element from the top level. The path must follow the same hierarchy as the structure panel.

Correct Option:

B. BlockA:BlockB:Action1 ✔️ Correct
This option is correct because it uses the proper colon (:) delimiter and the correct hierarchy order. In an Integration Procedure, to reference an element nested inside other blocks, you must use a colon-delimited path that starts from the top-level block and goes down to the target element (BlockA:BlockB:Action1). The output JSON structure mirrors the structure panel's hierarchy.

Incorrect Options:

A. BlockA.BlockB.Action1 ❌ Incorrect
This option uses periods (.) instead of colons (:) as delimiters. OmniStudio Integration Procedures require colons to specify a path when referring to an element's location in the data JSON structure. Periods are not the correct syntax for referencing data nodes in Send JSON Path fields.

C. Action1:BlockB:BlockA ❌ Incorrect
This option reverses the hierarchy order of the structure. In a Send JSON Path, you must refer to the element's location from the top-level parent down to the target element (parent:child:target). The target element should appear last in the path, not first.

D. Action1.BlockB.BlockA ❌ Incorrect
This option uses both the incorrect delimiter (periods) and the incorrect hierarchy order (target first). This is a combination of the two errors found in the other incorrect options, making it completely invalid as a Send JSON Path reference.

🔧 Reference:
→ Salesforce Help: Response Action Properties for Integration Procedures - Confirms that colon-delimited paths are used to specify a level below the top level for a key/value pair in the Send JSON Path field.

→ Trailhead: Configure Your Integration Procedure - Provides foundational guidance on configuring Integration Procedures and using colon-delimited paths for referencing nested elements.

Explanation:

The question tests how OmniScript Block elements structure data in the output JSON, specifically for a Checkbox inside Block2 and a Multi-Select element inside Block3. Blocks create nested objects in the Data JSON. Multi-select values combine selected options (Value A and Value B) into a single field.

✅ Correct Option:
Option A correctly represents the nested Block structure. The Checkbox (Checkout) appears as a boolean under its Block node. The Multi-Select value uses the proper syntax for selected options from Block3 (Value A and Value B). This matches standard OmniScript Block behavior for grouping input elements into hierarchical JSON.

❌ Incorrect options:
Option B does not satisfy the requirement. It uses incorrect nesting for the Blocks. The Multi-Select and Checkbox values are misplaced, and the JSON hierarchy does not follow OmniScript rules for Block elements.

🔧 Reference:
→ Salesforce Help: Combine Elements Logically in a Block
Confirms Blocks create nested JSON for grouped elements like checkboxes and multi-selects.

Explanation:

This question tests common causes of partial data loss when an OmniScript displays data returned from an Integration Procedure. The root issues are usually incorrect mapping between OmniScript element names and JSON keys, or incorrect trimming of the response payload via Response JSON Path configuration.

Correct Option:

✔️ A: The element name for the missing data does not match the JSON node key in the Integration Procedure Response.
OmniScript binds data from Integration Procedure responses to UI elements using the element name as the JSON key. If the element name does not exactly match the corresponding key in the Integration Procedure’s Response data (including case and spelling), the binding fails and that data will not be displayed, resulting in missing values for that field.

✔️ D: The missing data is trimmed in the Integration Procedure Action Response JSON Path.
In the OmniScript’s Integration Procedure Action, the Response JSON Path property defines which JSON node from the Integration Procedure output is returned. If this path is set to a narrower node that does not include all required fields, some data will be excluded (trimmed) from the returned payload. As a result, those fields are absent when the OmniScript tries to display the data.

Incorrect Options:

❌ B: The Integration Procedure Preview Input Parameters do not match the JSON sent from the OmniScript.
The Preview Input Parameters in the Integration Procedure Designer affect how the IP behaves in the preview environment, but they do not change the runtime behavior when called from OmniScript. At runtime, the IP uses its defined Input Parameters, so this mismatch does not directly cause specific data fields to be missing in the response.

❌ C: The JSON sent from the Integration Procedure Action does not match any of the Original Input for the Integration Procedure.
This option is not a valid cause. The Integration Procedure does not require the JSON sent from OmniScript to match the “Original Input” shown in the designer. It uses the defined Input Parameters to receive data. A difference between the JSON structure and the preview’s Original Input does not inherently cause data to be missing in the returned response.

🔧 Reference:
→ Salesforce Help: Retrieve Data with an Integration Procedure in an Omniscript
Confirms that the Response JSON Path and Response JSON Node properties control which part of the Integration Procedure output is returned to the OmniScript, and that incorrect configuration can trim or exclude data.

→ Salesforce Help: Manipulate JSON with the Send/Response Transformations Properties
Explains how Response JSON Path specifies the JSON node that contains the output returned to the OmniScript, and how misconfiguration can result in data being excluded from the final payload.

Explanation

This question tests understanding of how to combine core Integration Procedure elements to build a complete data flow: retrieving Salesforce data, processing it with custom Apex logic, and returning the result to the calling process. Each of the three required steps maps directly to a specific, purpose-built Integration Procedure action.

✅ Correct Options

B. Response Action
The Response Action tells the Integration Procedure what data to send back to the entity that called it, whether that's an OmniScript, FlexCard, or external REST client. This step completes the flow by returning the processed result to the caller.

C. Data Mapper Extract Action
The Data Mapper Extract Action calls a Data Mapper Extract to read data from Salesforce and return it into the Integration Procedure's Data JSON. This is the starting point for the flow, retrieving the Salesforce records needed before any custom processing takes place.

D. Remote Action
The Remote Action calls a specified Apex class and method to perform custom processing on the retrieved data. Since the requirement is to process the data using an Apex class, this action is essential for executing that business logic within the Integration Procedure.

❌ Incorrect Options

A. Data Mapper Post Action
A Data Mapper Post Action writes data to Salesforce objects rather than retrieving or returning data to a caller. Since the requirement doesn't involve saving data back to Salesforce, this action isn't part of the described flow.

E. HTTP Action
An HTTP Action executes a REST call to an external system and returns its results to the Integration Procedure. Since the scenario only involves getting Salesforce data and processing it with Apex, no external REST callout is required, making this action unnecessary here.

Reference:
→ Salesforce Help: Integration Procedure Actions — confirms the roles of the Data Mapper Extract Action, Remote Action, and Response Action within an Integration Procedure's data flow.