OmniStudio-Developer Practice Test Questions

Summary
When troubleshooting a DataRaptor Extract, the most efficient first step is to use the integrated Preview tab within the DataRaptor interface itself. This tool allows you to execute the DataRaptor in isolation by providing a sample JSON input. It immediately shows the output or any errors, confirming whether the issue lies within the DataRaptor's configuration (like the JSON extract map) or elsewhere in the integration.

Correct Option

B. Go to the PREVIEW tab In OmniScript to test.
This is the correct first step because the Preview tab is a dedicated, controlled environment for testing DataRaptors. You can provide a specific input JSON that mimics what your OmniScript would send, and the tab will display the exact output the DataRaptor returns.

This isolates the DataRaptor's functionality. If it fails here, the problem is definitively within the DataRaptor's configuration (e.g., an incorrect field mapping or object relationship). If it works here, the issue likely lies in how it's being called from the OmniScript or Integration Procedure.

Incorrect Option

A. Go to the Lightning Console and reload the page to test.
This is an inefficient first step. Reloading an entire application page involves many other components (the OmniScript, layouts, other data sources). It does not isolate the DataRaptor, making it difficult to pinpoint the root cause of the data retrieval issue.

C. Deactivate the card and layout, and go to the PREVIEW tab for the card to test.
This approach is overly complex and indirect for the stated goal. The Card's Preview tab tests the entire card, not just the DataRaptor. Deactivating components is unnecessary when a direct testing tool for the specific component in question is available.

D. Add a key/value pair in the DataRaptor to test it.
Modifying the DataRaptor by adding new elements should not be the first troubleshooting step. The correct initial action is to diagnose the current configuration using the Preview tool. Making changes before understanding the problem can introduce new errors and is not a systematic debugging approach.

Reference
Salesforce OmniStudio Developer Guide: Test a DataRaptor

Explanation:

Account information must always be visible → This should be placed in a standard block or text elements on the FlexCard, no conditional logic needed.

Contact information should only be visible when needed → The best pattern is to place the contact details inside a block element and then set its collapsible property.
This adds an expand/collapse toggle, allowing the user to click and show/hide the content on demand.
This is a common design choice when you want "on-demand visibility" for secondary information.

❌ Why the other options are incorrect:

A. Use a Data table element → A data table is for listing multiple records (e.g., lists of contacts), not for selectively showing details about a single contact. Doesn’t solve the show/hide requirement.

B. Set the class ‘collapsible’ on the block element → This isn’t the right approach. You don’t manually set a CSS class to make FlexCard elements collapsible. There’s a built-in property for that.

D. Use a conditional FlexCard State → States are used to render different layouts based on conditions (e.g., error, active, inactive). Not appropriate here — we don’t want different layouts, just toggled visibility.

📖 Reference:
Salesforce OmniStudio FlexCard Designer Guide → Block Elements:
“Block elements can be configured with the collapsible property, which lets users expand or collapse the section content.”

Summary
When an OmniScript launches from a FlexCard but fails to display Salesforce data, the issue is typically a broken data bridge between the card and the script. The FlexCard must pass the correct record ID to the OmniScript, and the OmniScript's DataRaptor must be configured to receive and use that ID to fetch data. The problem lies in this handoff or data retrieval configuration, not in the activation state of the components.

Correct Option

A. The Id Field for Actions in the FlexCard is blank.
This is a primary cause. For the OmniScript to load data for a specific record, the FlexCard's action must pass the record ID. If the "Id Field for Actions" property is blank, the FlexCard sends a null ID to the OmniScript. Consequently, the DataRaptor Extract inside the OmniScript has no record to query, resulting in empty data fields.

D. In the DataRaptor Extract Action, the Input Parameters Filter Value is misspelled.
This directly breaks the data retrieval. The OmniScript receives the ID from the FlexCard as a variable. This variable must be correctly mapped to the DataRaptor's input parameter. A misspelled filter value means the DataRaptor does not receive the ID, causing it to run without a filter and return no data for the intended record.

Incorrect Option

B. There is no active version of the Data Raptor Extract.
This is unlikely to be the cause. An OmniScript cannot reference an inactive DataRaptor. If the DataRaptor were inactive, the OmniScript would fail to load altogether or throw a clear error, rather than displaying with empty data. The activation state is enforced by the platform.

C. There is no active version of the OmniScript.
This is incorrect. The scenario states that the "OmniScript displays," which would be impossible if there were no active version. A user cannot launch an inactive OmniScript from a FlexCard. This error would prevent the script from opening entirely.

Reference
Salesforce OmniStudio Developer Guide: Configure Actions for a FlexCard

Summary
The issue is that while the DataRaptor runs successfully (as seen in the Debug Log), its extracted data is not being included in the final response of the Integration Procedure. An Integration Procedure's response is built by explicitly defining what data to return. Without a final step to package the data, the procedure will execute all actions but return an empty JSON object to the calling client.

Correct Option

C. A Response Action was not added to the Integration Procedure.
The Response Action is a dedicated element that must be the final step in an Integration Procedure. Its purpose is to define the structure of the JSON response. Even if previous actions like a DataRaptor Extract run correctly and store data in the pipeline, this data is not automatically sent back. Without a Response Action to map the pipeline data into the response, the output will always be empty.

Incorrect Option

A. The DataRaptor Action did not have the Add Response To Response JSON property set to true.
This property is used to merge a DataRaptor's output directly into the final response JSON, which can be useful in specific cases. However, it is not the primary or required method for returning data. A properly configured Response Action can return the data regardless of this setting on the individual DataRaptor action.

B. The Response cannot be previewed directly.
This is incorrect. The Preview tab for an Integration Procedure is specifically designed to show the final JSON response. If the Integration Procedure is configured correctly with a Response Action, the preview will display the returned data. The ability to preview the response is a core feature of the tool.

D. The AccountId used for the preview is invalid.
The scenario states that the developer "sees the data extracted by the DataRaptor in the Debug Log." This is definitive proof that the DataRaptor ran successfully and found data for the provided AccountId. If the ID were invalid, the DataRaptor would have returned an empty result or an error, which would be visible in the debug log.

Reference
Salesforce OmniStudio Developer Guide: Response Action

Summary
The requirement is to retrieve a field (Name) from a parent object (Account) for a starting record (Contact). In a DataRaptor, this is accomplished by leveraging a lookup relationship. The correct approach is to define the extraction starting from the source object (Contact) and then use a JSON Path that traverses the relationship field (Account) to the target field (Name), without needing separate extraction steps for each object.

Correct Option

A. Define an extraction step for the Contact object and set the Extract JSON Path to Contact.Account.Name
This is the correct and most efficient best practice. A single DataRaptor Extract step starting from the Contact object can traverse the Account relationship to get the Account.Name using the JSONPath Contact.Account.Name. The DataRaptor internally handles the SOQL join, eliminating the need for multiple, manually configured extraction steps and simplifying the configuration.

Incorrect Option

B. Define extraction steps for the Contact and the Account objects, and set the Extract JSON Path to Contact.Account.Name
This is redundant and not a best practice. Defining a separate step for the Account object is unnecessary because the relationship from Contact to Account can be traversed directly in the JSON Path within a single step. Multiple steps would complicate the DataRaptor without providing any benefit for this simple lookup.

C. Define extraction steps for the Contact and the Account objects, and set the Extract JSON Path to Account.Name
This is incorrect. The JSON Path Account.Name is not rooted in the starting object of the extraction. The first step is based on the Contact object, so the pipeline data at that point is a Contact record. Referring directly to Account.Name without the Contact. prefix would be invalid as the context is wrong.

D. Define an extraction step for the Account object, and set the Extract JSON Path to Account.Contact.Name
This reverses the relationship logic. The requirement is to start from a Contact and get its parent Account's name. This option starts from the Account and tries to traverse to a child Contact (Account.Contact.Name), which is not a standard relationship and would not work. The relationship is Contact.Account, not Account.Contact.

Reference
Salesforce OmniStudio Developer Guide: Configure a DataRaptor Extract

Summary
In OmniStudio, when data is passed from a parent component to a child component, such as from a parent FlexCard to a child FlexCard, it is received as a parameter. The child component does not directly access the parent's data context. Instead, it must reference the specific parameter name that was defined in the data passing configuration. The syntax to reference these passed-in values uses the Params namespace.

Correct Option

D. {Params.postalcode}
This is the correct syntax. The Params object is the designated namespace for accessing any data passed into a FlexCard from an external source, including a parent card. When the parent card passes the postal code, it becomes a named parameter in the child card's context. Using {Params.postalcode} (or the exact parameter name defined in the action) allows the child card's text element to correctly display the received value.

Incorrect Option

A. {Postalcode}
This syntax would only work if "Postalcode" were a field on the base record that the child FlexCard is directly querying for itself. Since the data is being passed from the parent, it exists in the parameters collection, not in the root data context of the child card.

B. {Parent.postalcode}
There is no built-in Parent namespace for directly accessing a parent component's data within a child FlexCard. Data must be explicitly passed from parent to child using parameters. This syntax is invalid and will not resolve to any value.

C. {Records.postalcode}
The Records namespace is typically used within the parent FlexCard itself to reference fields from the record(s) it queried. A child card does not automatically inherit this context. The child card must receive the data via parameters and then reference it using Params.

Reference
Salesforce OmniStudio Developer Guide: Configure Actions for a FlexCard

Summary
To pass all records from a parent FlexCard to a child FlexCard, the developer must reference the correct data context node from the parent's data source. The parent FlexCard's query typically returns a collection of records, which is stored in a default node. The child component needs access to this entire collection to display it in its own DataTable.

Correct Option

B. {Records}
This is the correct node to use. In a parent FlexCard, the {Records} node represents the root array of records returned by the card's DataRaptor or query. By setting this as the source in the parent's action configuration, the entire collection of records is passed to the child card. The child card can then bind its DataTable directly to the received parameter, which will now contain the full set of data.

Incorrect Option

A. {Records[0]}
This syntax refers only to the first record ([0]) within the {Records} array. Passing this would send a single object representing the first record to the child card, not the entire collection. The child's DataTable would not have the full list of records to display.

C. {Params.records}
The Params namespace is used within a child component to access data passed into it. In the parent card's configuration, you reference your own local data context ({Records}), not a Params object. Using {Params.records} in the parent would imply the parent is expecting to receive data, which is the reverse of the intended data flow.

D. {Recorded}
This is an invalid and non-existent node within the OmniStudio context. The standard and reserved node name for the collection of records in a FlexCard is {Records}. Using {Recorded} would result in no data being passed to the child card.

Reference
Salesforce OmniStudio Developer Guide: Configure Actions for a FlexCard

Summary
When previewing an Integration Procedure, the output panel shows a detailed JSON structure representing the execution. Each element in the procedure has its own node containing its specific result. The Response Action is the final element that defines the procedure's output, and its results are displayed in a node named after the action itself, allowing developers to verify the exact data being returned.

Correct Option

D. ResponseCart
This is the correct node. In the Integration Procedure's preview debug output, each action has a dedicated JSON node named after the action's "Name" property. The ResponseCart node will contain the final, structured JSON output as defined by the mapping within that specific Response Action. This is the definitive data that the Integration Procedure would send back to the calling OmniScript or application.

Incorrect Option

A. FetchCart
The FetchCart node shows the input, output, and debug information for the Remote Action, not the Response Action. It displays the request sent to the external service and the raw response received from it, which is the data that will be fed into the pipeline for the Response Action to use.

B. Response
While "Response" is the type of the action, it is not the node name used in the debug output. The preview uses the custom name assigned to the action instance by the developer (in this case, ResponseCart), not its generic type. The node Response does not exist in this context.

C. ResponseCartDebug
This is a fabricated node name. The debug output does not append "Debug" to action names. The primary output and result of the Response Action named ResponseCart is contained directly within the ResponseCart node itself.

Reference
Salesforce OmniStudio Developer Guide: Test an Integration Procedure

Summary
The issue is a data type mismatch where a field value extracted from Salesforce is being cast as a string in the resulting JSON, but the external service requires an integer. The solution requires actively converting the data type before it is placed in the output. This type conversion is not handled by simple configuration in the Output tab but requires a data manipulation step.

Correct Option

D. In the DataRaptor Formula tab, define a formula using the function TOINTEGER and use the formula as output.
This is the correct and most direct solution. The Formula tab allows you to apply functions to your data. By creating a formula that uses the TOINTEGER() function on the source field, you explicitly convert the string value to a number. You then map this formula's result to the output field instead of the original source field, ensuring the JSON contains an integer.

Incorrect Option

A. In the DataRaptor Output tab, select the Output Data Type of that field to Integer.
The "Output Data Type" dropdown in the Output tab (e.g., String, Number, Boolean) is primarily for documentation and has limited functional impact on the actual JSON structure for basic extracts. It does not reliably perform type conversion. The field will often still be serialized as a string in the final JSON output.

B. In the DataRaptor Output tab, enter the default value as 0 on the field.
Setting a default value only provides a fallback if the source field is null or empty. It does not change the data type of an existing value. If the source field contains the string "123", the default value is ignored, and "123" is still sent as a string. This does not solve the type conversion problem.

C. In the DataRaptor Extract tab, set the Input Data Type field to Integer.
The "Input Data Type" in the Extract tab defines the data type of the parameters being passed into the DataRaptor (e.g., the filter value). It has no effect on the data type of the fields being extracted from the Salesforce object and output by the DataRaptor.

Reference
Salesforce OmniStudio Developer Guide: DataRaptor Formula Functions

Summary
The requirement is to retrieve data for a single field from a Salesforce record directly within an OmniScript. This is a common need for populating a field based on a selected record ID, such as getting an Account's phone number after an Account Id is entered. The element must perform a lightweight, real-time data lookup without the overhead of a full DataRaptor or external call.

Correct Option

A. Lookup
The Lookup element is specifically designed for this purpose. It is a dual-purpose element that provides a searchable interface to find a record and, upon selection, can automatically populate other fields on the OmniScript with data from that selected record. Its "Pre-fill Field Mappings" property allows a developer to map a field from the selected record (e.g., Account.Phone) to a field in the OmniScript, efficiently retrieving the value for a single field.

Incorrect Option

B. Select
The Select element is used to present a static or dynamically sourced list of options for a user to choose from (like a picklist). It does not perform a real-time data retrieval from a Salesforce record based on an ID. It is for user selection, not for auto-populating field values from a database.

C. HTTP Action
An HTTP Action is used to call an external REST API or web service. It is not the right tool for a simple, internal data retrieval from a Salesforce record. Using it for this purpose would be overly complex, require custom Apex, and violate the principle of using the simplest tool for the job.

D. DataRaptor Post Action
A DataRaptor Post Action is used to create, update, or upsert records in the database. It is a data loading tool, not a data retrieval tool. For extracting a single field value, a DataRaptor Extract would be more appropriate, but even that is more heavyweight than a Lookup element for this specific single-field use case.

Reference
Salesforce OmniStudio Developer Guide: Lookup Element