Summary
The requirement is to pass specific data nodes from the Integration Procedure's pipeline as discrete parameters to an Apex method via a Remote Action. The Apex method expects named parameters (AccountId and ProductId), not a monolithic JSON object. The correct configuration must explicitly map each pipeline value to its corresponding Apex method parameter.

Correct Option

A. Check the Send Only Additional Input checkbox, and add the following Key/Value pairs to Additional input:
This is the correct configuration. The "Send Only Additional Input" option ensures that only the explicitly defined key/value pairs in the "Additional Input" section are sent to the Apex method. Here, you would create two entries:

Key: accountId, Value: {%AccountId%}

Key: productId, Value: {%Details:ProductId%}

This maps the pipeline data directly to the expected Apex method parameters, ensuring they are passed by name correctly.

Incorrect Option

B. Set Return Only Additional Output to true, and add the following Key/Value pairs to additional input.
"Return Only Additional Output" controls what is returned from the action and stored in the pipeline, not what is sent to the action. Enabling this would not help in sending the correct input parameters to the Apex method and might even strip the response if not configured properly on the output side.

C. Check the DataRaptor Transform checkbox, and add the following Key/Value pairs to Output JSON Path:
The "DataRaptor Transform" checkbox is used to transform the response from the Apex call using a DataRaptor. It has no bearing on how the input parameters are structured or sent to the Apex method. The "Output JSON Path" is for mapping the action's result, not its input.

D. Add the following to Send JSON Path: accountId: %AccountId% ProductId: %Details:ProductId%
The "Send JSON Path" is used to send a single, structured JSON object as the input to the remote service. An Apex Remote Action expecting discrete named parameters will not be able to deserialize this single JSON string into its separate parameters correctly. The "Additional Input" method is the standard and correct way to pass multiple discrete parameters.

Reference
Salesforce OmniStudio Developer Guide: Remote Action

Summary
The card layout displays a single Account with multiple related Contacts. Each card combines the parent Account data with one of its child Contacts. The correct JSON structure must represent this one-to-many relationship in a way that the card layout can iterate over. The standard pattern is an array of objects, where each object contains both the parent record fields and the fields for a single child record.

Correct Option

C. Option C
This is the correct structure for a card layout with a one-to-many relationship. It presents an array of two objects. Each object contains:

The parent Account data (Name: "Acme", Phone: "2221546450")

The specific child Contact data for one record (e.g., ContactName: "Eduard Stancs", ContactCellPhone: "(212) 154-8562")

This format allows the card layout to create one card for each element in the outer array, with each card displaying the repeating Account information alongside a unique Contact.

Incorrect Option

A. Option A
This structure is invalid and illogical. It places the single Account object inside the same structure as the multiple Contact objects. A card layout using this would be unable to correctly associate one Account with multiple Contacts for iterative display, as the Account is not a peer to the Contacts in the array.

B. Option B
This structure is invalid JSON (mismatched brackets) and conceptually flawed. It tries to put the AccountPhone and AccountName at the same level as the Contact array, but not as a structured object. More importantly, it does not provide a clear, iterable array where each element contains the combined Account and Contact data needed to render individual cards.

Reference
Salesforce OmniStudio Developer Guide: FlexCard Data Sources

Summary
The requirement is to execute one of two different calculations based on the value of a Boolean variable (isCustomer). In a Calculation Procedure, this conditional logic is implemented using the "Conditional Step" property on individual Calculation Steps. This allows the procedure to evaluate a condition for each step and only execute that step if the condition is true, providing a clear, structured way to handle branching logic.

Correct Option

A. Use two separate Calculation Steps with the Conditional Step property selected: use the ISTRUE (isCustomer) and NOT (ISTRUE(isCustomer)) functions in the Condition syntax.
This is the correct and most explicit method. It involves creating two distinct Calculation Steps.

The first step has its Conditional Step property enabled with the condition ISTRUE(isCustomer). This step's formula will only execute if isCustomer is true.

The second step also has Conditional Step enabled with the condition NOT(ISTRUE(isCustomer)). This step's formula will only execute if isCustomer is false.

This ensures that only one of the two calculations runs, providing clean and reliable conditional logic.

Incorrect Option

B. Use two separate Calculation Steps with the Conditional Step property selected: reference just the isCustomer variable in the Conditional syntax (no comparison necessary)
This is incorrect. The condition field must evaluate to a Boolean value. Simply referencing isCustomer without a function or operator is syntactically invalid in the condition syntax. The condition must be a full expression, such as ISTRUE(isCustomer).

C. Use two separate Calculation Steps with the Conditional Step property selected: compare the isCustomer variable directly to the literal true and false values in the Condition syntax.
This approach is flawed. You cannot compare a variable directly to the literals true or false in the Calculation Procedure's condition syntax. The correct way to check a Boolean variable is to use the ISTRUE() or ISFALSE() functions. A direct comparison like isCustomer == true would not be recognized.

D. Use a single Calculation Step with an IF statement directly in the formula definition to reference the isCustomer variable and conditionally perform the appropriate calculation.
While a single complex formula with an IF statement might work in some contexts, it violates the principle of using the dedicated "Conditional Step" feature for this purpose in Calculation Procedures. Using Conditional Steps is the more declarative, manageable, and best-practice approach for this scenario, as it keeps the individual formulas simpler and the logic flow more visible.

Reference
Salesforce OmniStudio Developer Guide: Calculation Step Properties

Summary
To limit the number of records returned by a DataRaptor Extract, the configuration must be applied within the DataRaptor itself. This ensures the limit is enforced at the database query level, which is the most efficient approach. Applying the limit at the source reduces the data volume processed by the platform and guarantees that only the specified number of records is ever retrieved, regardless of how the DataRaptor is called.

Correct Option

C. Use the LIMIT filter on the Extract definition
This is the correct and most efficient method. In the DataRaptor Extract's configuration, under the "Filter" section, you can add a LIMIT clause. Setting this to 1 ensures the underlying SOQL query includes LIMIT 1, so the database returns only one record at most. This is a best practice as it optimizes performance by restricting results at the source.

Incorrect Option

A. Define a formula with the Filter function
Formula functions operate on data after it has been retrieved from the database. Using a FILTER function would first fetch all records matching the query and then apply the limit in memory. This is inefficient for large data sets and does not prevent the performance cost of initially retrieving multiple records.

B. Use a Custom Output Type when creating the DataRaptor
The Custom Output Type determines the structure of the returned JSON (e.g., "SObject" vs. "Custom"). It does not have a setting to limit the number of records returned by the query. This configuration is unrelated to result set sizing.

D. Set the Limit Property on the Action that calls the DataRaptor Extract.
There is no standard "Limit" property on the Integration Procedure or OmniScript action that calls a DataRaptor. The limiting logic must be defined within the DataRaptor's own configuration. The calling action can pass parameters to the DataRaptor but cannot directly impose a row limit on its results.

Reference
Salesforce OmniStudio Developer Guide: Configure a DataRaptor Extract

Summary:
This question involves identifying the correct JSON structure for the DRGetAccountDetails action to display account and contact information in an OmniScript with a Repeat Block (BlkContacts). The UI shows fields for Account Name, Account Phone, Contact Name, and Contact Phone, with multiple contact entries, requiring proper nesting and repetition to reflect all six values.

Correct Option:

C. Option C
Option C correctly uses "BlkContacts" as a Repeat Block with an array containing two contact objects, each with "ContactPhone" and "ContactName" (e.g., "(212) 169-1475" for "Edward Stamos" and "(212) 189-8797" for "Leanne Tomlin"). It also includes "AccountPhone" and "AccountName" at the root level, matching the UI's six values.

Incorrect Option:

A. Option A
Option A lacks the "BlkContacts" Repeat Block structure and only includes one contact entry, missing the second contact (Leanne Tomlin). This fails to display all six values and does not align with the repeatable contact section.

B. Option B
Option B includes multiple fields at the root level without a "BlkContacts" array, incorrectly mixing contact and account data. This structure does not support the Repeat Block and misrepresents the UI layout.

D. Option D
Option D uses "Phone" and "name" instead of "ContactPhone" and "ContactName" within "BlkContacts", which does not match the field labels in the UI. This inconsistency prevents correct data mapping.

Reference:
Salesforce Help: OmniScript Designer