Explanation:

This question tests your understanding of core software engineering design patterns and best practices as applied to OmniStudio declarative development.

✅ Correct Option:

D. It promotes reusability and modularity of server-side logic
By encapsulating a common, repeatable sequence of actions (such as fetching localized data or checking inventory) into a dedicated Sub-Integration Procedure, you establish a single source of truth. Any parent Integration Procedure can call this child block using the **Integration Procedure Action**. This approach dramatically reduces redundant development effort, simplifies maintenance (since changes only need to be made in one place), and ensures consistent execution across your platform.

❌ Incorrect options:

A. It enables the child Integration Procedure to run asynchronously.
While you can configure a Sub-Integration Procedure to run asynchronously using properties like Chainable, this is a technical execution configuration rather than the core architectural advantage of nesting procedures instead of duplicating logic.

B. It avoids the need for exception handling.
Sub-Integration Procedures do not eliminate the need for exception handling. In fact, you must still explicitly manage errors using Try-Catch Blocks inside either the child or parent procedures to gracefully handle run-time failures.

C. It ensures the entire process runs in one transaction.
Calling a Sub-Integration Procedure can actually partition execution contexts (for example, if using chainable or queueable actions to break limits), so it does not strictly guarantee a single transaction context. Even if it did, running in a single transaction is not the primary benefit of avoiding duplicated configurations.

🔧 Reference:
→ Salesforce Help: Salesforce Help: Integration Procedure Action for Integration Procedures - Discusses how to call reusable, modular child processes from a parent Integration Procedure.

Explanation:

This question tests your understanding of how an Integration Procedure returns data during execution. Although the Data Mapper Extract successfully retrieves data, the response remains empty unless a Response Action is configured to send the required data from the Integration Procedure's JSON to the caller.

🟢 Correct Option:

C. A Response Action was not added and Data Mapper output was not mapped to the Send JSON Path:
A Response Action controls what data an Integration Procedure returns to the caller. Even though the Data Mapper Extract successfully retrieves the Account data, the output remains empty if the extracted data is not mapped through the Response Action's Send JSON Path. Both the Response Action and proper mapping are required to return the expected response.

🔴 Incorrect Options:

A. The Data Mapper Action did not have the Add Response To Response JSON property set to true:
The Data Mapper Extract successfully executed, as confirmed by the Debug Log. While the Add Response To Response JSON setting affects how data is stored in the response JSON, a properly configured Response Action is still required to return that data to the caller.

B. The AccountId used for the preview is invalid:
An invalid AccountId would prevent the Data Mapper Extract from retrieving data. Since the Debug Log clearly shows that the Data Mapper successfully extracted the record, the AccountId is valid and is not the cause of the empty response.

D. A Response Action was not added to the Integration Procedure:
A missing Response Action can result in no data being returned. However, even when a Response Action exists, the extracted data must also be mapped to the Send JSON Path. Therefore, this option is less complete than option C, which identifies both required configurations.

🔧 Reference:
⇒ Salesforce Help – Integration Procedure Response Action
Explains how the Response Action and the Send JSON Path determine which data an Integration Procedure returns to the calling process.

Explanation:

This question tests the understanding of how OmniScripts receive context data when embedded on Lightning record pages. Lightning pages automatically pass the current record ID to embedded components using the specific parameter name recordId .

✔️ Correct Option:

Option C:
When an OmniScript is embedded on a Lightning record page, the platform automatically passes the current record ID to the component using the parameter name recordId . To automatically receive this value, the OmniScript must be configured with an input variable named exactly recordId .

❌ Incorrect options:

Option A:
ContextId is not automatically passed by Lightning record pages. This parameter name would require manual mapping or configuration to receive the record ID .

Option B:
While AccountId or other object-specific IDs are valid parameter names, they are not automatically populated by Lightning pages. The automatic parameter is specifically recordId .

Option D:
CurrentRecord is not a standard parameter name recognized by Lightning pages for passing record context. Only recordId is automatically provided .

🔧 Reference:
→ Salesforce Help: Lightning Web Components and OmniScript - Explains that recordId is automatically passed when embedding OmniScripts on record pages.

→ Trailhead: Embed an OmniScript in a Lightning Record Page - Confirms that recordId is the parameter name used for automatic record context.

Explanation:

This question tests your understanding of performance optimization, specifically platform caching strategies in OmniStudio Integration Procedures (IP).

✅ Correct Option:

A. Set the Cache Duration to 300 seconds, or 5 minutes.
When designing an Integration Procedure for high-volume transactions where the source data is modified frequently (in this case, every 5 minutes), the most appropriate solution is to set the Cache Duration (Time to Live) to match that exact update frequency (300 seconds / 5 minutes). This allows the platform to serve read requests from memory for high-volume performance benefits while ensuring that as soon as the 5-minute threshold is reached, the cache expires and a fresh database call is automatically triggered to reload the newest data.

❌ Incorrect options:

B. Set the Contextual Cache Key to a unique value.
Setting a contextual cache key controls how cached entries are partitioned (for example, caching by Account ID or User ID). It does not configure or automate the time-based expiration of the cached dataset itself.

C. Disable caching, as the data changes too frequently.
Disabling caching entirely solves the data freshness issue but fails to meet the requirement for a "high-volume process". High-volume processes must minimize database round trips to avoid reaching Salesforce governor limits; caching for a short window (5 minutes) is the correct compromise.

D. Set the Cache Duration to a very high value, for example, 24 hours.
Setting a long duration (like 24 hours) will cause the platform to return stale, outdated cached records to users for nearly an entire day. It fails the business requirement to ensure the data is updated shortly after it changes every 5 minutes.

🔧 Reference:
→ Salesforce Help: Cache for OmniStudio Integration Procedures - Outlines how to configure top-level and cache block durations to optimize high-volume transactional flows.

Explanation:

This question tests the understanding of Data Mapper configuration tabs and where to define outputs for formula results. In a Data Mapper, the Output tab is where developers specify the structure of the final JSON output, including fields derived from formulas, to ensure they are available in the resulting JSON.

✔️ Correct Option:

Option D:
The Output tab defines the final JSON structure that the Data Mapper produces. After creating a formula, you must map its result to an output field on this tab to include it in the Data Mapper's JSON output. This makes the combined identifier available for subsequent actions or components.

❌ Incorrect options:

Option A:
The Transform tab is used for mapping input JSON to intermediate structures or performing transformations, not for defining the final output fields of a formula result.

Option B:
The Mapping tab is used for mapping input fields to Salesforce fields or target objects in a Data Mapper Load, not for defining formula outputs in the JSON.

Option C:
The Extract tab is used for defining query parameters and filters when retrieving data, not for mapping formula results to output fields.

🔧 Reference:
→ Salesforce Help: Data Mapper Overview - Explains the purpose of the Output tab for defining JSON output structure.

→ Trailhead: Data Mapper Transform - Covers configuring output fields in the Output tab for formula results.