✅ Explanation:

When making a GET request to a REST API that requires query parameters (e.g., ?city=London&country=UK), the HTTP Action in an Integration Procedure provides a dedicated Query Parameters section. This section allows you to define key-value pairs that are automatically appended to the endpoint URL as a properly formatted query string. This is the standard and recommended method because it handles URL encoding automatically, keeps the configuration clean, and maintains separation between the base URL and dynamic parameters.

Why other options are incorrect:

A. Define the parameters only in the HTTP Action Request Body:
This is incorrect for GET requests. The Request Body is used for POST, PUT, or PATCH methods where data is sent in the payload. For GET requests, query parameters are appended to the URL, not placed in the body.

C. Use a Data Mapper Load action to send the parameters directly to the external API:
This is incorrect. DataRaptor Load is used to write data to Salesforce objects, not to send parameters to external APIs. It cannot bypass the HTTP Action, which is the only OmniStudio element that makes external callouts.

D. Manually concatenate the parameters into the endpoint URL using a Set Values action:
This is discouraged. While it would technically work, it is error-prone, requires manual URL encoding handling, and creates unnecessary complexity. The Query Parameters section in the HTTP Action provides a cleaner, declarative alternative.

🔗 References

Salesforce OmniStudio Developer Guide → "For GET requests, use the Query Parameters section in the HTTP Action to define key-value pairs that are automatically appended to the endpoint URL."

✅ Explanation:

The requirement is to fetch Case details after the user has selected a Case in Step 1, and display those details in Step 2. The most efficient and architecturally sound approach is to use a DataRaptor Extract Action placed between Step 1 and Step 2. This action dynamically takes the CaseId captured in Step 1 as an input filter, queries Salesforce to retrieve only that specific Case record, and returns the details. This ensures the data is fresh, minimizes the query payload, and is loaded just in time for Step 2.

Why this is the best practice:

Efficient: Only one record is queried using a selective filter (Id), minimizing SOQL query costs.

Real-time data: The Case data is fetched at the moment it is needed, ensuring it reflects the latest state.

Clean separation: Data retrieval logic is encapsulated in a DataRaptor Action, keeping the OmniScript flow clean and maintainable.

Why other options are incorrect:

A. Use a Data Mapper Load to read the Case data:
Incorrect. The DataRaptor Load type is used for writing/upserting data to Salesforce, not for reading/querying. To retrieve Case details, the consultant should use a DataRaptor Extract type.

B. Fetch all Cases in the Init action and filter them in Step 2:
Incorrect and inefficient. Fetching all Cases in the Init action would query potentially thousands of records, causing performance degradation, unnecessary SOQL usage, and memory overhead—even if a filter is later applied client-side. Data should be queried selectively, not bulk-fetched.

D. Ask the user to re-enter the Case details in Step 2:
Incorrect. This creates a poor user experience, introduces data entry errors, and defeats the purpose of automation. The system should pre-populate the Case details automatically based on the selected Case ID.

🔗 References

Salesforce OmniStudio Developer Guide → "Use DataRaptor Extract Actions in OmniScripts to retrieve Salesforce data on-demand using input parameters from previous steps."

✅ Explanation:

The best practice for handling errors and status messages within an Integration Procedure (IP) is to explicitly return a structured response using a Response action. This action maps the IP's final output JSON, which should include:

A Boolean isSuccess element indicating whether the operation succeeded or failed.
A errorMessage element containing a user-friendly error description when isSuccess is false.
A successMessage element (optional) confirming successful updates.

This approach provides the client-side OmniScript with clear, predictable status information—enabling it to display appropriate messages to the user, perform conditional branching, or trigger error handling logic. It also separates business logic errors from system-level exceptions, making the IP more maintainable and user-friendly.

Why other options are incorrect:

A. Use an HTTP Action at the end to send the status message to the client: HTTP Actions are used to make outbound API calls, not to return responses to the caller. The Response action is the intended method for returning data from an IP.

C. Rely solely on the client-side OmniScript to detect failure by checking empty data:
This is unreliable. An IP can fail for many reasons (e.g., DML exception, callout timeout) while still returning some data—or it may succeed with empty data legitimately. A dedicated status flag is the only reliable way to communicate success/failure.

D. Assume success if the IP completes without throwing a system error:
System errors (e.g., governor limits) are only one type of failure. Business logic errors (e.g., validation rule failure, record not found) do not throw system exceptions but still represent a failure. Relying on "no exception" alone is insufficient.

🔗 References

Salesforce OmniStudio Developer Guide → "Use the Response action to define the output structure of an Integration Procedure, including status indicators and error messages for the calling component."

Explanation:

A single massive OmniScript that attempts to handle Sales, Service, and Billing inquiries introduces significant architectural risks. While it may seem simpler to have "everything in one place," this monolithic approach leads to:

Complexity in branching logic: Managing multiple distinct business flows (Sales, Service, Billing) within one script creates tangled conditional logic. Steps and blocks become interdependent, making the script difficult to understand, modify, or debug.

Difficulty in testing: A single massive script cannot be tested in isolation. Every change risks breaking unrelated flows. Unit testing becomes nearly impossible, and regression testing requires testing the entire script end-to-end.

Slower load times: OmniScripts load all their elements (steps, blocks, elements, data sources) at initialization. A massive script with hundreds of elements will take longer to render, degrading user experience, especially on slower networks or mobile devices.

Best Practice: Break the monolithic script into focused, reusable child OmniScripts—one for Sales, one for Service, and one for Billing—and call them conditionally from a parent OmniScript. This improves maintainability, testability, and performance.

Why Other Options Are Incorrect

A. Improved performance due to caching:
This is incorrect. Caching can improve performance, but a massive script is slower to load because it must parse all elements at startup—caching does not mitigate this initial load overhead.

B. Easier maintenance as everything is in one place:
This is a misconception. While a monolith may seem simpler initially, it becomes increasingly difficult to maintain as complexity grows. Changes in one area can break unrelated areas, and understanding the full script requires navigating hundreds of elements.

D. Reduced number of components in the org:
While this is technically true, it is not a benefit. Reducing component count by creating monolithic scripts violates modular design principles and introduces the risks listed above. The goal is not to minimize component count but to maximize maintainability and reusability.

🔗 References

Salesforce OmniStudio Best Practices→ "Break large OmniScripts into smaller, reusable child OmniScripts to improve maintainability, testability, and performance."

✅ Explanation:

The OmniStudio User permission set is the baseline runtime permission set that enables a user to view and interact with (run/execute) OmniStudio components like FlexCards and OmniScripts. It provides the necessary access to consume these tools in the user interface without granting any design, configuration, or editing capabilities.

Why Other Options Are Incorrect

A. Modify All Data:
This is a powerful system-level permission granting full read/write access to all data, which is far beyond what is needed and would violate the principle of least privilege.

B. Customize Application:
This permission grants the ability to modify application metadata and build components, enabling editing, not just viewing and interacting.

D. OmniStudio Admin:
This permission set grants full administrative rights, including the ability to create, edit, and deploy OmniStudio components—contradicting the requirement of "should not be able to edit them".

🔗 References

Trailhead/Setup Documentation: To access OmniStudio features, users must be assigned the OmniStudio User permission set for baseline runtime access. Separately, OmniStudio Designer enables creation and editing capabilities, confirming that the "User" variant is for consumption only.

Salesforce Help: The "Required Permission" property on OmniStudio Data Mappers and Integration Procedures can be set to control runtime execution access, which can include the OmniStudio Admin permission set for administrative users.