OmniStudio-Developer Practice Test

Salesforce Spring 25 Release -
Updated On 10-Nov-2025

95 Questions

A developer examines data received from an external data source. The data is nested two levels down in the JSON structure.
Which OmniStudio tool could the developer use to simplify this data?

A. A guided workflow

B. A DataRaptor Transform

C. An HTTP Action Element

D. An integration Procedure

B.   A DataRaptor Transform

Explanation

When data comes from an external system and is nested multiple levels down in a JSON structure, the best OmniStudio tool to flatten, reshape, or simplify the JSON is:

✔ DataRaptor Transform (DR Transform)
A DataRaptor Transform is specifically designed to:
- Flatten deeply nested JSON
- Map complex structures into simple key/value JSON
- Restructure the data before passing it to OmniScripts, FlexCards, or Integration Procedures
This makes it the ideal tool for simplifying incoming JSON.

Why the other options are incorrect:
A. Guided Workflow
❌ Used for orchestrating steps and user flows — not for restructuring JSON data.

C. HTTP Action Element
❌ Sends/receives external API calls but cannot transform or simplify JSON.

D. Integration Procedure
✔ Can orchestrate data transformations
❌ BUT for JSON restructuring, it still relies on a DataRaptor Transform action inside it.

…… configure Additional input to send exactly the same data? Assume that the develop checkedSend Only Additional input.

A. Option A

B. Option B

C. Option C

D. Option D

D.   Option D

Explanation:

The question asks how to configure the Additional Input to send exactly the same data as the primary input, given that the "Send Only Additional Input" checkbox is selected. This means the primary "Send JSON Path" will be ignored, and only the data defined in the "Additional Input" section will be sent.

The goal is to make the "Additional Input" replicate the data that was originally going to be sent from the DRExtractAction:Account node.

Let's analyze the options in the exhibit:

Option A:
Key: SecondaryAccount
Value: DRExtractAction:Account

Analysis: This is incorrect. It creates a new node called SecondaryAccount and puts the entire contents of DRExtractAction:Account inside it. The structure sent would be { "SecondaryAccount": { ...account data... } }, which is not the same as the original flat account data.

Option B:
Key: DRExtractAction:Account
Value: SecondaryAccount

Analysis: This is incorrect. It tries to create a node named DRExtractAction:Account and populate it with the contents of a node called SecondaryAccount. However, SecondaryAccount does not exist or is not the source of the data we want to send. This would likely result in an empty or incorrect payload.

Option C:
Key: *DRExtractAction:Account
Value: SecondaryAccount

Analysis: This is incorrect. The asterisk (*) syntax is used in the Response JSON Path to extract all elements from an array. It is not standard syntax for mapping in the Additional Input section for this purpose. This configuration is invalid for replicating the object data.

Option D:
Key: SecondaryAccount
Value: DRExtractAction:Account

Analysis: This is correct. Wait, this appears identical to Option A. There must be a critical difference in the exhibit that isn't fully conveyed in the text. Let's re-analyze based on standard OmniStudio behavior.

The key is the placement of the merge field symbol #. The correct syntax to assign the value of one node to another is to use the merge field.

The correct configuration should be:
Key: SecondaryAccount
Value: #DRExtractAction:Account#

If Option D is the one that correctly uses the merge field syntax (#DRExtractAction:Account#) as the Value, while Option A uses the plain text (DRExtractAction:Account), then Option D is correct. The merge field copies the entire data structure, while the plain text would be treated as a literal string.

Reference
To clone a data node in the "Additional Input" section:
- The Key defines the name of the new node in the outgoing JSON.
- The Value must be a merge field (e.g., #OriginalNode#) that references the node you want to copy.

Therefore, the correct option is the one where the Key is the desired new node name (e.g., SecondaryAccount) and the Value is the merge field reference to the original data node (e.g., #DRExtractAction:Account#).

Based on the standard functionality and the pattern of the options, D is the correct choice, assuming it is the one that properly uses the merge field syntax to copy the data.

A healthcare company wants to enable its subscribers to add, edit, or delete dependents related to their policy via their Community portal. The developer on the project decides to use an OmniScript.
How should the developer configure the OmniScript to provide this functionality?

A. Use an Edit Block element configured with Remote Actions.

B. Use a Text Block element and a Remote Action element.

C. Use an Input Block element and a Data Mapper Post Action element.

D. Use an Edit Block element configured with SOQL statements.

A.   Use an Edit Block element configured with Remote Actions.

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.

In an Expression Set, what is required for the output of a Calculation Step to be used in an Aggregation Step?

A. It must be included in constants.

B. It must be included in the output.

C. It must be a calculation step.

B.   It must be included in the output.

Explanation

This question tests your understanding of the data flow and scoping within an OmniStudio Expression Set. The key is knowing which data is available to subsequent steps.

Calculation Step: Performs row-by-row calculations and creates new values for each record.
Aggregation Step: Performs summary calculations across the entire dataset.

For an Aggregation Step to use the result of a Calculation Step, the calculated value must be part of the dataset that the Aggregation Step receives.

A. It must be included in constants.
Incorrect. Constants are predefined static values and do not include dynamic results created in a Calculation Step.

B. It must be included in the output.
Correct. The Output section determines which fields continue to the next step. If the calculated field is not added to the Calculation Step’s output, it is discarded and not available to the Aggregation Step.

C. It must be a calculation step.
Incorrect. Being a calculation step does not automatically make the field available. Only fields included in the Output are passed forward.

Summary
Data does not automatically flow between steps in an Expression Set. Each step must explicitly define which fields move forward using its Output configuration.

Process Flow:
1. A Calculation Step computes a value (e.g., LineTotal).
2. The field is added to the Calculation Step’s Output.
3. The Aggregation Step receives LineTotal.
4. The Aggregation Step can perform operations such as SUM(LineTotal).

Therefore, the calculated field must be included in the output of the Calculation Step.

Refer to the exhibit below.



What is the reason that the fields fail to display the fetched data?

A. Lookup Mode is selected in the properties of the Type Ahead Block.

B. FirstName, LastName, and BirthDate are not placed inside the Type Ahead Block.

C. The typeHead key is not in the correct format.

D. Use Data JSON is Not selected in the properties of the Type Ahead Block.

D.   Use Data JSON is Not selected in the properties of the Type Ahead Block.

Explanation:

A Type Ahead Block in OmniScript only displays returned data if "Use Data JSON" is enabled.
When this setting is not selected, the component does not bind the fetched data to the fields such as:
- FirstName
- LastName
- BirthDate
Even if the data is successfully retrieved, the fields inside the Type Ahead Block will appear empty because the component is not instructed to use the data from the Data JSON.

Why the other answers are incorrect:
A. Lookup Mode selected
Lookup Mode does not prevent fetched data from appearing; it simply changes how the search works.

B. Fields not placed inside the Type Ahead Block
In the screenshot, they are structured under the Type Ahead container (they appear nested in the left panel).

C. TypeAhead key not in correct format
The key format would affect searching, not rendering the retrieved data.

Page 1 out of 19 Pages