Explanation:

This question tests your understanding of the Integration Procedure Preview feature. During preview, each executed element creates a corresponding JSON node that contains its input and output data, making it easier to inspect the information passed between actions for troubleshooting and validation.

🟢 Correct Option:

C. FetchCart:
In the Integration Procedure Preview, each element generates a JSON node using its element name. Since the Remote Action is named FetchCart, the data sent to and returned from that action is available under the FetchCart node. This allows developers to inspect the request and response while debugging the Integration Procedure.

🔴 Incorrect Options:

A. ResponseCart:
The ResponseCart node represents the output generated by the Response Action. It contains the final data returned by the Integration Procedure rather than the information passed into the Remote Action. Therefore, it is not the correct location for inspecting the Remote Action's input data.

B. FetchCartDebug:
Integration Procedure Preview does not automatically create a separate node with a Debug suffix. The Preview JSON uses the configured element names directly. As a result, a node named FetchCartDebug is not generated for inspecting the Remote Action's execution.

D. ResponseCartDebug:
A node named ResponseCartDebug is not created by the Integration Procedure Preview. Debug information is displayed within the existing element nodes rather than separate debug nodes. Therefore, this option does not represent where the Remote Action's data can be viewed.

🔧 Reference:
⇒ Salesforce Help – Integration Procedure Preview
Explains how the Preview tool displays execution data for each Integration Procedure element using its configured element name.

Summary
Configuring the Input JSON for a DataRaptor that will be used within an OmniScript requires an accurate representation of the data structure available in the OmniScript's data JSON at the point where the DataRaptor will be called. The most reliable method to obtain this structure is to use the actual data generated by the OmniScript itself during testing, ensuring perfect alignment between the DataRaptor's expected input and the data the OmniScript will provide.

Correct Option

C. Copy the Input JSON from the OmniScript {Data} modal.
This is the best practice approach. While building an OmniScript, you can use the Preview mode and open the {Data} modal (often accessible via a button in the preview toolbar). This modal shows the exact, live data JSON structure at the current step. Copying this JSON and pasting it into the DataRaptor's "Input JSON" tab provides the most accurate blueprint for defining the input mapping, as it reflects the real data context.

Incorrect Option

A. Copy the Input JSON from the DataRaptor Action Debug node.
The DataRaptor Action Debug node shows the input after it has been processed and sent to the DataRaptor. This is useful for troubleshooting why a DataRaptor failed, but it is not the source for initially building the Input JSON schema. You need the source structure from the OmniScript to define the mapping first.

B. Build the Input JSON node by node in an editor.
Manually building the JSON structure is error-prone and time-consuming. It relies on the developer's memory or documentation of the OmniScript's data structure, which can easily lead to mismatches between the DataRaptor's expected input and the actual data provided by the OmniScript.

D. Build the Input JSON node by node in the DataRaptor Designer.
While the DataRaptor Designer provides tools to build the structure, it is still a manual process that is disconnected from the actual OmniScript data. The most efficient and accurate method is to import the real, generated JSON from the OmniScript's {Data} modal directly.

Reference
Salesforce OmniStudio Developer Guide: Configure a DataRaptor Load

Explanation

This question tests understanding of how FlexCard preview modes differ. "View Data" pulls data directly using the actual record context, while "Preview Layout" relies on the Record Id configured in the Test Data Source Settings. If that test Record Id is invalid or mismatched, the layout preview fails even though live data works correctly.

✅ Correct Options

B. Record Id in Test Data Source Settings is for the wrong record type
The DataRaptor data source uses params.id to filter data based on a specific object type. If the Record Id entered in the Test Data Source Settings belongs to a different object type than what the DataRaptor expects, the query returns no matching data, causing the layout preview to fail to render.

D. No Salesforce record exists for the Record Id used
The Test Data Source Settings require a valid, existing Record Id to simulate real data during layout preview. If that Record Id does not correspond to an actual Salesforce record, the DataRaptor cannot retrieve any data, so the FlexCard layout has nothing to render and stays blank.

❌ Incorrect Options

A. The Data Node field is empty
An empty Data Node field would typically cause a broader structural failure affecting both View Data and Preview Layout modes. Since View Data already displays valid data successfully, the Data Node is clearly configured correctly, ruling this out as the cause of the preview-only failure.

C. Attributes haven't been configured to pass data to fields
Attribute misconfiguration would prevent fields from populating even when valid data is returned successfully by the data source. Since the issue here is that data isn't returned at all during preview, the root cause lies in the Test Data Source Record Id, not in field-level attribute mapping.

Reference:
→ Salesforce Help: Configure an Omnistudio Data Mapper Data Source on a Flexcard (Managed Package) — confirms Test Data Source Settings require a valid Record Id to preview live FlexCard layouts correctly.

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

Explanation:

This question tests how to style parts of a FlexCard differently using Block elements. The requirement is to visually distinguish less critical attributes by using a different font size and overall styling, while keeping the configuration simple and maintainable.

Correct Option:

✔️ A: Set a unique CSS Class on the second Block and apply custom styling to it.
Using a unique CSS Class on the second Block is the most straightforward and scalable approach. You set the CSS Class on the Block element, then define custom styling (such as smaller font size, lighter color, etc.) in the FlexCard’s CSS. This applies the same styling to all elements inside that Block without needing to configure each Text element individually, making it easy to maintain and update.

Incorrect Options:

❌ B: Manually adjust the font size properties on each Text element within the second Block.
Manually setting font size on each Text element is repetitive and not maintainable. If the design changes, you must update every element separately. This approach also increases the risk of inconsistent styling and is not considered a best practice compared to using a CSS Class.

❌ C: Set the Layout property of the second Block to Small.
The Layout property in FlexCards controls the arrangement of elements (e.g., row, column), not visual styling like font size. There is no “Small” layout option that automatically reduces font size or applies distinctive styling. This option does not address the requirement.

❌ D: Use a State element to apply conditional styling to the second Block.
States are used for conditional UI behavior based on data (e.g., showing different styles when a record is in a certain status). They are not needed here because the requirement is static: the second Block should always be styled differently. Using States would add unnecessary complexity and logic.

🔧 Reference:
→ Salesforce Help: Set Up Card Actions to Update a Flexcard
Confirms that FlexCard elements support CSS Classes and custom styling, enabling developers to apply consistent visual distinctions across groups of elements like Blocks.

→ Salesforce Developer: Build a FlexCard with External Data (PDF)
Illustrates how to configure FlexCard layout and styling, including use of CSS and Block elements, supporting the approach of using CSS Classes to style different sections of a FlexCard.