Summary
When a FlexCard field displays its label but no value, it indicates a data mapping issue where the target field exists in the card's layout but the data source is not providing a value for it. The most common cause is that the specific field is empty (null) on the Salesforce record retrieved by the DataRaptor. The FlexCard renders the label as defined in the layout, but has no data to display for the value.

Correct Option

B. The field is null on the Salesforce record.
This is the most direct and likely cause. The FlexCard's DataRaptor successfully retrieved the record, which is why other fields display data. However, for this specific field, the value on the Salesforce record is blank (null). The FlexCard correctly renders the label defined in the designer but has no data to populate the value, resulting in an empty space next to the label.

Incorrect Option

A. The fields have exceeded the maximum number allowed on the card.
There is no strict, low limit (like 15 total elements) on the number of fields and actions a FlexCard can contain. If a maximum were exceeded, it would more likely cause broader rendering issues or errors, not a single field failing to display its data while others work correctly.

C. {recordId} is misspelled in the Data Source Input Map.
A misspelled {recordId} in the Data Source Input Map would prevent the DataRaptor from executing correctly for the specific record context. This would cause a complete data retrieval failure, meaning none of the fields would display data, not just a single field.

D. There are no test parameters configured.
Test parameters are used for previewing the FlexCard in the builder. If test parameters were missing, the card would fail to load data during preview. The scenario implies testing is occurring, and since most fields display correctly, the DataRaptor is successfully running and receiving a valid record ID, ruling this out as the cause.

Reference
Salesforce OmniStudio Developer Guide: Troubleshoot FlexCards

Summary
When embedding an LWC OmniScript within a parent LWC OmniScript, data is passed between them using the Lightning Message Service (LMS) via a feature called LWC PubSub. For a value set in the parent script to be available in the embedded script, the Set Values element in the parent that holds the data must be configured to broadcast this data. If this broadcast flag is not enabled, the embedded script cannot receive the data, even if the parent script has the value correctly set in its own context.

Correct Option

C. The LWC PubSub Message flag in the Set Values action of the parent has not been set.
This is the specific configuration required to pass data from a parent LWC OmniScript to an embedded one. The "LWC PubSub Message" checkbox on the Set Values element in the parent OmniScript must be checked. This enables the data to be published via the Lightning Message Service, making it available for the embedded OmniScript to subscribe to and consume. Without this flag set, the data remains isolated within the parent's context.

Incorrect Option

A. Both parent and embedded OmniScripts have the same element name for the Set values element.
While it is a best practice to use unique element names for clarity, having the same name for Set Values elements in parent and embedded scripts does not prevent data from being passed via LWC PubSub. The PubSub communication is based on the "LWC PubSub Message" setting and the structure of the data, not on the element names themselves.

B. A developer failed to include a Navigation Element to pass data from the parent OmniScript.
A Navigation Element is used to control the user's flow between steps within a single OmniScript. It is not the mechanism for passing data between a parent and an embedded OmniScript. Data passing for embedded scripts is handled by the LWC PubSub configuration on elements like Set Values.

D. The flag passDataJSON in the parent OmniScript in not configured correctly.
There is no standard property named "passDataJSON" in the OmniScript configuration. Data passing in embedded LWC OmniScripts is handled by the LWC PubSub mechanism, not by a generic property with this name.

Reference
Salesforce OmniStudio Developer Guide: Embed an OmniScript in an OmniScript

Summary
The "Send Only Additional Input" checkbox means the action will send only the data defined in the "Additional Input" section and ignore the standard data pipeline. To pass data from a previous action (DRExtractActionAmount) to a parameter in the next action (SecondaryAccount), the "Additional Input" mapping must be configured correctly. The Key is the target parameter name in the receiving action, and the Value is the source of the data from the pipeline.

Correct Option

A. Option A
Key: SecondaryAccount - This is the correct target parameter name in the receiving action that will hold the passed value.

Value: {DRExtractActionAmount} - This is the correct merge field syntax to reference the output of the previous action named DRExtractActionAmount. The curly braces {} are used to pull data from the Integration Procedure's data pipeline. This configuration will successfully map the output of the DataRaptor Extract action to the SecondaryAccount input parameter.

Incorrect Option

B. Option B
This option reverses the Key and Value. The Key becomes the source (DRExtractActionAmount) and the Value becomes the target ({SecondaryAccount}). This is syntactically incorrect and would attempt to find a data node called SecondaryAccount to pass to a parameter called DRExtractActionAmount, which does not fulfill the requirement.

C. Option C
This option is incorrect on both sides. The Key uses an invalid syntax (+...*) and the Value uses an incorrect merge field format (%...%). Merge fields in Integration Procedure Additional Inputs use curly braces {}, not percent signs.

D. Option D
This option has the correct Key (SecondaryAccount) but an incorrect Value. DRExtractActionAmount without the surrounding curly braces {} is interpreted as a literal text string, not a reference to the output of the previous action. It would pass the text "DRExtractActionAmount" instead of the data it holds.

Reference
Salesforce OmniStudio Developer Guide: Integration Procedure Data Pipelining

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

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