OmniStudio-Developer Practice Test Questions (2026)

Explanation:

For allowing Community users to add, edit, and delete dependents linked to a policy, the best OmniScript component is:

✔ Edit Block
Built specifically for managing repeating records (create, update, delete).
Ideal for scenarios like dependents, addresses, contacts, etc.
Automatically supports Add, Edit, Remove functions for each row.

✔ Remote Actions
Remote Actions allow the OmniScript to:
Retrieve dependent records
Update or create new dependents
Delete dependents via Apex or Integration Procedures, making it secure for Community users.

Why the other options are incorrect:
B. Text Block + Remote Action
❌ Text Blocks cannot handle editable list data.

C. Input Block + Data Mapper Post
❌ Input Blocks collect input but cannot support add/edit/delete rows dynamically.

D. Edit Block + SOQL
❌ Direct SOQL in OmniScript is not a best practice and not supported. Data retrieval must use DataRaptors, Integration Procedures, or Remote Actions.

Explanation

If an OmniScript (OS) needs to be reused across many customer interactions—especially as a common step like updating billing information—the correct way to invoke it is using an OmniScript Action.

Why OmniScript Action?
An OmniScript Action allows you to:
- Launch one OmniScript from another
- Reuse a common OmniScript as a sub-flow
- Maintain consistency across multiple customer journeys
- Avoid duplicating logic

This is the intended approach when a process (like billing updates) is reusable and shared across many user flows.

❌ Why the others are incorrect

B. Custom Action
Custom Actions are used mainly in FlexCards, not OmniScripts.
They are for FlexCard buttons, not for embedding or reusing an OmniScript.

C. Lightning Action
Lightning Actions are for Salesforce Lightning pages, not for assembling OmniScripts together. They don’t enable reuse inside OmniScripts.

Explanation:

Let’s figure this out step by step! In the exhibit, the Integration Procedure element is set up with SEND/RESPONSE TRANSFORMATIONS. The "Send JSON Path" is set to DRExtractAction:Account, and the "Send JSON Node" is set to SecondaryAccount. This means the data from DRExtractAction:Account will be sent and labeled as SecondaryAccount. Now, the question asks how to configure the "Additional Input" to send the same data, with the "Send Only Additional Input" option checked.

When you use "Additional Input" with "Send Only Additional Input," you need to pass the data using a key-value pair. The key will be the name you want (like SecondaryAccount), and the value will be the data source (like DRExtractAction:Account). So, the correct way is to set the key as SecondaryAccount and the value as DRExtractAction:Account. That matches option A!

Option B uses %DRExtractAction:Account%, which is a merge field syntax. This is used for dynamic values in OmniScripts, not for direct data mapping in this case, so it’s not right.

Option C switches the key and value, making DRExtractAction:Account the key and SecondaryAccount the value, which is the opposite of what we need.

Option D also uses %DRExtractAction:Account% and swaps the order, so it’s incorrect too.

Think of it like giving a nickname to some data. You name it SecondaryAccount (the key) and point it to the data in DRExtractAction:Account (the value). Option A does this perfectly!

Reference: Salesforce OmniStudio Developer Guide

Explanation:

This question tests your knowledge of the different Invoke Modes for an Integration Procedure Action within an OmniScript and their impact on the user experience and data flow.

The key requirements are:
- The OmniScript needs to call the Integration Procedure.
- The OmniScript does not need to wait for the response for the user to proceed.

This describes an asynchronous operation where the backend process is decoupled from the user's navigation through the script.

Let's analyze each option:

A. Use Future: This is incorrect. "Use Future" is a property within an Integration Procedure step (like a DataRaptor Transform or HTTP Action) that makes that specific step asynchronous on the server. It does not control the behavior of how the OmniScript interacts with the IP. The OmniScript would still wait for the entire IP to report back its final status.

B. Invoke Mode Non-Blocking: This is incorrect. "Non-Blocking" is a legacy term. In modern OmniStudio, the equivalent and precise setting is "Fire and Forget." Using the specific terminology from the product is crucial for the exam.

C. Invoke Mode Fire and Forget: This is the correct answer. When you set the Invoke Mode of an Integration Procedure Action to "Fire and Forget", the OmniScript sends the request to the IP and immediately continues to the next step without waiting for a response. The user can proceed with the OmniScript uninterrupted. The IP executes in the background. This perfectly matches the requirement that the user does not need to wait.

D. Toast Completion: This is incorrect. "Toast Completion" is a feature that, when enabled, displays a temporary notification message (a "toast") to the user upon the successful completion of the action. It is a UI feedback mechanism, not a control for the execution flow. The script would still wait for the IP to finish before showing the toast and proceeding, which violates the "does not need to wait" requirement.

Summary
The Invoke Mode on an Integration Procedure Action controls the OmniScript's waiting behavior:
- Blocking (Default): The OmniScript pauses and waits for the IP to fully complete and return a response before moving forward.
- Fire and Forget: The OmniScript triggers the IP and moves on immediately. It does not receive any response data from the IP, and any errors in the IP are not reported back to the OmniScript.

Therefore, to allow the user to proceed without waiting for the JSON response, the developer must enable Invoke Mode: Fire and Forget.

Summary:
This question assesses the ability to match a JSON structure to an OmniScript configuration displayed in the Structure panel. The panel shows a step with two blocks: Block1 (Text1 and Telephone1 fields) and Block2 (Checkbox1 and Multi-select fields). The correct JSON must accurately reflect this hierarchy and field names without extra or missing elements.

Correct Option:

C. Option C
Option C correctly represents the step with "Block1" containing "Text1" and "Telephone1" fields, and "Block2" containing "Checkbox1" and "Multi-select" fields. The JSON structure aligns with the UI, using proper nesting and including all specified fields with appropriate values, matching the OmniScript design.

Incorrect Option:

A. Option A
Option A includes an erroneous "Block3" with "Multi-select" and "Checkbox1" misplaced, which does not match the UI's two-block structure. This extra block and incorrect field placement make it an invalid representation.

B. Option B
Option B separates "Checkbox1" and "Multi-select" into different blocks ("Block2" and "Block3"), which does not align with the UI showing both under Block2. This misplacement disrupts the intended structure.

D. Option D
Option D lacks proper nesting under "Block2" for "Checkbox1" and includes a space in "Multi - select", which does not match the field name in the UI. This inconsistency renders it incorrect.

Reference:
Salesforce Help: OmniScript Designer

Summary
A Set Values element with a hardcoded ContextId is a common technique used for testing an OmniScript in a development or sandbox environment, as it allows the developer to simulate working with a specific record. However, hardcoded IDs are org-specific and will be invalid in a production org. Leaving such testing artifacts in a production-bound component is poor practice and will cause runtime errors.

Correct Option

C. Delete or Deactivate the Set Values element.
This is the correct and safest course of action. The Set Values element with the hardcoded ContextId was a testing scaffold, not part of the actual business logic. Before promoting to production, this testing element should be removed entirely (deleted) or, if it contains other necessary values, deactivated so it does not execute. The production OmniScript should receive its context (like a Record Id) dynamically from the launching point (e.g., a FlexCard, Lightning record page, or Community), not from a hardcoded value.

Incorrect Option

A. Update the ContextId value to specify an id from the Production org.
This is an anti-pattern and should never be done. Hardcoding any record ID in a component makes it non-portable and brittle. The ID will likely not exist in all target orgs, and even if it does, the script will only work for that single record, which is not the intended behavior.

B. Add a Show/Hide condition on the Set Values element.
Adding a condition does not solve the core problem. The element would still be present in the configuration. If the condition were to somehow evaluate to false in production, the ContextId would never be set, breaking the script's logic that depends on it. The correct approach is to remove the testing artifact, not to hide it.

D. Deactivate the contextId key/value pair
Most Set Values elements do not have an activation checkbox for individual key/value pairs. Even if this were possible, it would leave behind unnecessary configuration clutter. The entire purpose of the element was for testing, so the cleanest and most correct practice is to remove the element itself.

Reference
Salesforce OmniStudio Developer Guide: OmniScript Best Practices

Explanation:

When building a DataRaptor Load that will be used by an OmniScript, the most reliable and accurate way to get the correct JSON structure for mapping is to capture it directly from the source. The OmniScript's {Data} modal in the debug pane provides a real-time, exact representation of the JSON data that the OmniScript has collected.
By copying the JSON from this modal, you ensure that the Input JSON in your DataRaptor matches the naming and hierarchy of the data being passed by the OmniScript. This minimizes errors and simplifies the mapping process, ensuring a smooth and successful data load into Salesforce.

Why Other Options Are Not Best Practices?

A. Build the Input JSON node by node in an editor:
This is prone to human error. You might misspell a node name, get the hierarchy wrong, or miss a required field. This can lead to a broken DataRaptor that is difficult to debug.

B. Build the Input JSON node by node in the DataRaptor Designer:
Similar to building in an external editor, this approach relies on manually recreating the JSON structure. While you are in the correct tool, it's still not the most accurate method compared to using the actual JSON output from the OmniScript.

D. Copy the Input JSON from the DataRaptor Action Debug node:
The DataRaptor Action Debug node is part of the Integration Procedure's debug log. While useful for seeing the data flow within the Integration Procedure, it's a step removed from the OmniScript itself. The most direct and reliable input source for a DataRaptor Load invoked by an OmniScript is the OmniScript's own data JSON.

Summary
The requirement is to execute one of two different calculations based on the value of a Boolean variable (isCustomer). In a Calculation Procedure, this conditional logic is implemented using the "Conditional Step" property on individual Calculation Steps. This allows the procedure to evaluate a condition for each step and only execute that step if the condition is true, providing a clear, structured way to handle branching logic.

Correct Option

A. Use two separate Calculation Steps with the Conditional Step property selected: use the ISTRUE (isCustomer) and NOT (ISTRUE(isCustomer)) functions in the Condition syntax.
This is the correct and most explicit method. It involves creating two distinct Calculation Steps.

The first step has its Conditional Step property enabled with the condition ISTRUE(isCustomer). This step's formula will only execute if isCustomer is true.

The second step also has Conditional Step enabled with the condition NOT(ISTRUE(isCustomer)). This step's formula will only execute if isCustomer is false.

This ensures that only one of the two calculations runs, providing clean and reliable conditional logic.

Incorrect Option

B. Use two separate Calculation Steps with the Conditional Step property selected: reference just the isCustomer variable in the Conditional syntax (no comparison necessary)
This is incorrect. The condition field must evaluate to a Boolean value. Simply referencing isCustomer without a function or operator is syntactically invalid in the condition syntax. The condition must be a full expression, such as ISTRUE(isCustomer).

C. Use two separate Calculation Steps with the Conditional Step property selected: compare the isCustomer variable directly to the literal true and false values in the Condition syntax.
This approach is flawed. You cannot compare a variable directly to the literals true or false in the Calculation Procedure's condition syntax. The correct way to check a Boolean variable is to use the ISTRUE() or ISFALSE() functions. A direct comparison like isCustomer == true would not be recognized.

D. Use a single Calculation Step with an IF statement directly in the formula definition to reference the isCustomer variable and conditionally perform the appropriate calculation.
While a single complex formula with an IF statement might work in some contexts, it violates the principle of using the dedicated "Conditional Step" feature for this purpose in Calculation Procedures. Using Conditional Steps is the more declarative, manageable, and best-practice approach for this scenario, as it keeps the individual formulas simpler and the logic flow more visible.

Reference
Salesforce OmniStudio Developer Guide: Calculation Step Properties

Explanation:

A Calculation Procedure is used to perform complex multi-step calculations. Its structure involves:

Calculation Steps: These steps perform the individual operations (e.g., formulas, matrix lookups).
Aggregation Step: This final step gathers results from the calculation steps to produce the overall procedure output.
For the result of a calculation step to be available for use in the Aggregation Step, it must be explicitly defined in the Calculation Output of that step.

Here’s the logical flow:
Each calculation step has its own Input and Output configuration.
The fields listed in a step's "Calculation Output" are the results that step produces.
The Aggregation Step can only reference and combine outputs that have been declared in the Calculation Output of previous steps.
If a value is computed but not included in the Calculation Output of its step, it is considered an intermediate variable and is not passed forward to the Aggregation Step.

Why the other options are incorrect:

A. It must be included in constants:
Constants are fixed values defined in the procedure's setup. They are input into calculation steps, not the output from them.

B. It must be a matrix lookup step:
The type of step (e.g., Formula, Matrix Lookup) does not matter. Any step—whether it's a Formula, Matrix Lookup, or another type—must have its result included in its Calculation Output to be used later.

C. It must be a calculation step:
This is tautological (true by definition). The output in question is already from a calculation step. However, this statement misses the specific requirement that the output must be explicitly declared to be passed on.

Reference:
Salesforce OmniStudio Documentation:
The "Calculation Procedures" section explains the data flow. It explicitly states that the Aggregation Step "aggregates the output from multiple calculation steps," meaning it can only use what those steps have emitted in their output.

Summary
Implementing a global cancel functionality that is available across all steps of an OmniScript requires a configuration at the script level, not by adding individual elements to each step. The LWC OmniScript provides a built-in mechanism for this in its setup configuration. This approach ensures consistency, reduces repetitive configuration, and leverages the framework's native navigation controls.

Correct Option

A. Check the Enable Cancel checkbox in the Setup tab under Cancel Options.
This is the correct and most efficient method. In the OmniScript's Setup tab, there is a section for Cancel Options. Checking the "Enable Cancel" checkbox activates a global cancel button in the OmniScript's header. This button is available on every step without any need for the developer to manually add navigation elements, ensuring consistent cancel functionality throughout the entire multi-step form.

Incorrect Option

B. Add a navigation Action inside each step and set the Component name to ‘’Cancel’’
This is inefficient and error-prone. It would require manually adding the same element to every single step. Furthermore, the "Component Name" property is not used to define a cancel action; it is related to the underlying Lightning Web Component type.

C. Add a navigation Action outside each step and set the Element Name to ‘’Cancel’’
Navigation elements cannot be placed outside of a step. All actionable elements must reside within a Step element in the OmniScript structure. This configuration is not possible.

D. Add a navigation Action inside each step and set the Element Name to ‘’Cancel’’
While this would technically work by placing a button in every step, it is a manual, repetitive process that violates the DRY (Don't Repeat Yourself) principle. It is not the best practice when a simple, global configuration option ("Enable Cancel") exists to achieve the same result more reliably and with less effort.

Reference
Salesforce OmniStudio Developer Guide: OmniScript Setup Properties