Explanation

When an OmniScript updates a Salesforce record using a DataRaptor Load, but only some fields update, the issue is usually related to incorrect JSON paths or incorrect record identification. These two errors directly cause partial updates.

🟩 C. The input JSON paths in the DataRaptor Load do not match the JSON from the OmniScript.
Why this causes issues:
A DataRaptor Load maps OmniScript JSON → Salesforce fields.
If the JSON paths do not match, some fields:
- Receive no value
- Are skipped during the update
Result → only some fields update in Salesforce.
➡ This is one of the most common causes of partial updates.

🟩 D. ContextId is misspelled in the merge code that passes the RecordId to the DataRaptor.
Why this causes issues:
The ContextId (or RecordId) tells the DataRaptor which record to update.
If misspelled or missing:
- DataRaptor may update the wrong record
- Or attempt to upsert, causing unpredictable field updates
The result can be:
- Partial updates
- Updates to the wrong record
- No update at all

❌ Why the other options are incorrect

A. Fields are read-only in Salesforce
If a field is read-only, the DataRaptor Load would fail the update for those fields.
But it would still correctly update all writable fields.
This could cause partial updates, but typically it triggers a visible validation error.
Less likely and not the Salesforce OmniStudio best-answer choice.

B. Preview tab has wrong record type
Preview tab has no effect on runtime execution.
It only helps test the mapping.
Wrong record type in preview cannot cause partial updates during script execution.

Explanation:

This question tests your understanding of the different types of DataRaptors and when to use the newer, more efficient Turbo variants. The key details in the requirement are:
- Retrieve data from a single object.
- The structure of the output data does not need to be changed.

Let's analyze each option:
A. Data Mapper Load: This is incorrect. A DataRaptor Load is designed to retrieve a single record from a Salesforce object based on its Record ID (the Id field). It is not the right tool for extracting a list of records or for querying based on other criteria.

B. Data Mapper Transform: This is incorrect. A DataRaptor Transform is used to reshape and transform data from one JSON structure to another. It does not retrieve data from a Salesforce object; it only transforms data that is already provided to it as input.

C. Data Mapper Extract: This is a plausible but less optimal answer. A classic DataRaptor Extract can retrieve data from a single object using a SOQL query. However, it is the older, less performant technology. Following current best practices, the Turbo variant should always be preferred for new development where possible.

D. Data Mapper Turbo Extract: This is the correct answer. A DataRaptor Turbo Extract is the modern and recommended tool for this specific use case. It is optimized to generate and execute a SOQL query to retrieve data from a single Salesforce object. Since the output structure doesn't need to be changed, the developer can simply map the required fields from the object directly to the output, and the Turbo Extract will handle the efficient data retrieval.

Reference
The best-practice hierarchy for data operations in OmniStudio is to use Turbo DataRaptors whenever possible due to their superior performance and simpler configuration.
- To retrieve a list of records from a single object: Use a Turbo Extract.
- To retrieve a single record by ID: Use a Turbo Load.
- To create/update/upsert a record: Use a Turbo Post.
The classic (non-Turbo) DataRaptors are generally reserved for more complex scenarios involving multiple, related objects or complex XML transformations, which are not required here. Therefore, for simply retrieving data from a single object without transformation, the Data Mapper Turbo Extract is the clear best practice choice.

Explanation:

✔️ A. Data Mapper Extract Action
The Data Mapper Extract Action is used to retrieve (read) data from Salesforce objects or other data sources.
It can extract single records, multiple records, or parent/child relationships.
Use it when you want to populate an OmniScript or FlexCard with Salesforce data.

✔️ C. Lookup Input Element
A Lookup Input Element in OmniScript can query Salesforce records dynamically.
Commonly used for picklists, auto-complete fields, or any selection based on Salesforce data.
It is another way to retrieve data without using DataRaptors.

❌ Why the other options are incorrect
B. Data Mapper Post Action
Sends data to an external endpoint or API.
Used for creating or updating records, not retrieving.

D. Data Mapper Load Action
Writes data to Salesforce objects (insert/update).
Not designed for retrieval.

Explanation:

When you need to calculate a sum of a field across multiple records (like BasePrice), the most efficient approach in OmniStudio Expression Sets is to use an Aggregation Step.

Why Aggregation Step?
Aggregation steps are specifically designed to perform aggregate functions on collections of data.

Supported functions include:
- SUM()
- AVG()
- MIN() / MAX()
- COUNT()

The Aggregation Step can process the entire array of records in one operation, making it efficient and declarative.

❌ Why the other options are incorrect
A. Sub Expression step as SUM(BasePrice)
Sub Expressions are designed for intermediate calculations within a single record or value.
They are not efficient for summing across multiple records.

B. Calculation Step as SUM(BasePrice)
Calculation steps perform field-level arithmetic, usually on single values.
They do not automatically aggregate a collection of records.

Explanation

This question tests your understanding of the critical difference between versioning and cloning an OmniStudio component, specifically a FlexCard. The decision hinges on whether you want to replace the existing component or create a new, parallel one.

Let's clarify the concepts:
Versioning: Creating a new version of an existing FlexCard. When this new version is activated, it replaces the old version everywhere it is used. Any Layout or App Page that references the FlexCard will automatically start using the newly activated version. This is used for updates, bug fixes, and improvements to the same component.

Cloning: Creating a completely new, separate FlexCard with a different name. The original FlexCard remains untouched and unchanged. This is used when you need a different variation of a card to be used in a new context, alongside the original.

Now, let's analyze the options:

A. The new version of the FlexCard will be used in a new Console, and the current version of the FlexCard should remain unchanged.
This scenario describes a need for cloning. Since the current version must remain unchanged, you cannot replace it with a new version. You need a separate, independent card.

B. Another team member is developing new actions, fields, and styling for the current version of the FlexCard.
This describes a development workflow. The act of creating a new version for development is standard, but the reason for the final activation would be to deploy those changes to all users, which aligns with versioning. However, the core reason in the question is about the deployment outcome, and this option doesn't explicitly state that outcome. Option D is a more direct and definitive reason.

C. The new and current versions will be displayed together on the same target.
This is a definitive reason for cloning. If both the old and new designs need to exist simultaneously on the same page or layout, they must be two separate, uniquely named components. Versioning would replace the old one, making this impossible.

D. All instances of the FlexCard must be updated with the changes.
This is the correct and primary reason for choosing versioning. If the goal is to universally update the card—for example, to change a field label for all users in all contexts where the card is used—then you must create a new version. Activating this new version will push the label change to "all instances of the FlexCard" automatically.

Summary / Reference
The decision-making process is straightforward:
- Use Versioning when you are making a change that should apply globally to every place the component is used. You are maintaining a single source of truth.
- Use Cloning when you need to create a new, independent variant of the component that will exist alongside the original.

Therefore, the factor that leads a developer to version a FlexCard is the requirement that all existing instances must receive the update.