Explanation:

The key constraints in this scenario are the high volume (millions of records) and the read-only, historical nature of the data.

Big Objects are specifically engineered by Salesforce to store and manage massive volumes of data (up to billions of records) directly within the platform. They provide consistent performance at scale and are ideal for historical or audit data that does not change frequently.

External Objects (via Salesforce Connect) allow the data to remain in an external data warehouse or database, fetching it on-demand without consuming Salesforce data storage limits.

FlexCard Compatibility: OmniStudio's FlexCards can easily display this data by using an OmniScript DataRaptor (Turbo Extract/Extract) to query Big Objects, or an Integration Procedure connecting to an external API/OData endpoint to fetch External Objects.

Why the other options are incorrect:

A is incorrect: Storing millions of rows of transaction history inside a single long text field breaks data structure, makes filtering/sorting impossible, and hits field character limits quickly.

C is incorrect: While standard custom objects can hold millions of records, doing so consumes a massive amount of expensive Salesforce data storage and can lead to performance degradation (large data volumes/LDV issues) if not indexed properly.

D is incorrect: The customer explicitly states they need to store and display this historical data, so avoiding it entirely does not fulfill the business requirement.

References:

Salesforce Architecture & Large Data Volumes (LDV): Salesforce officially recommends Big Objects or External Objects for archiving and reporting on millions of historical, read-only records to maintain system performance.

Explanation:

The core issue is that the legacy system is slow to respond, but the data only changes once a day. Enabling caching on the Integration Procedure directly addresses both problems . A Cache Block saves the output from the external API call after the first execution. For a set duration, all subsequent requests for the same data are served from this fast in-memory cache, completely bypassing the slow legacy system call and improving the user experience .

Why other options are incorrect:

A. Configure a REST data source with an increased timeout setting: Increasing the timeout would prevent an immediate error but would make the user wait longer (potentially over 5 seconds), which worsens the experience .

B. Configure an Integration Procedure with Chain On Step enabled: "Chain On Step" is not a standard, problem-solving feature for slow external calls. It is unrelated to caching or performance optimization for this scenario.

C. Configure a Data Mapper with filtering logic: Data Mappers are used for querying and transforming data from Salesforce objects, not for handling external system calls or caching their responses .

Reference:
Salesforce Help: Cache for OmniStudio Integration Procedures
Trailhead: Master Integration Procedure Designer Elements Effectively

Explanation:

The requirements call for two distinct interactive features that map directly to FlexCard capabilities:

Flyout action (D) for the popup window:
The requirement states that "a popup window will display additional information about the campaign, such as details about the members." In FlexCards, a Flyout is the dedicated feature for displaying supplementary information in a popover or modal window on demand. Flyouts can be configured to launch a child FlexCard or an OmniScript to show detailed member information, keeping the main card clean while providing drill-down capability.

OmniScript action (B) for the guided process:
The requirement specifies that "a button must initiate a guided process to add new leads to the campaign." The Action element in a FlexCard can be configured as an OmniScript action—a button that, when clicked, launches a specific OmniScript. This is the standard pattern for initiating guided, multi-step processes directly from a FlexCard, such as adding new leads to a campaign.

These two features work together seamlessly: the OmniScript action handles the guided lead addition workflow, while the Flyout action provides the detailed member information popup.

Why other options are incorrect:

A. Block element:
The Block element is used for layout and grouping of other elements within a FlexCard (e.g., creating rows or columns). It does not provide popup windows or launch guided processes. It is a structural container, not an interactive action feature.

C. DataTable:
The DataTable element displays tabular data (rows and columns) within a FlexCard. While it could show campaign members in a grid format, it cannot create popup windows or launch OmniScripts. The requirement specifically calls for a popup and a guided process button—neither of which a DataTable provides.

References:

Salesforce OmniStudio Developer Guide → "Use Flyout actions in FlexCards to display additional information in a popup window, such as details or child records."

Salesforce OmniStudio Developer Guide→ "Use OmniScript actions in FlexCards to launch guided processes from a button on the card."

Explanation:

Salesforce OmniStudio provides built-in metadata fields—specifically the Description and Internal Notes fields—on every component, including Integration Procedures, DataRaptors, OmniScripts, FlexCards, and individual elements (actions, steps, etc.). These fields are the most effective and maintainable place to store technical documentation because:

Self-contained: Documentation travels with the component during deployments (change sets, packages, or source control).

Always accessible: Developers and admins can view the notes directly within the OmniStudio Designer or through the component's detail page without leaving the platform.

Version-aware: Documentation can be updated alongside code changes in the same metadata deployment, ensuring consistency.

Searchable: Internal Notes are searchable in the OmniStudio tooling, making it easy to find components by purpose.

For an Integration Procedure, the consultant should:
Document the overall purpose, inputs, outputs, and dependencies in the procedure-level Description field.

Add element-level comments in the Internal Notes of each action (e.g., HTTP Action, DataRaptor, Decision) to explain business logic, API endpoints, error handling, and transformation rules.

This approach aligns with governance board requirements while keeping documentation current, discoverable, and version-controlled.

Why other options are incorrect:

A. In the name of the Integration Procedure:
Component names are limited in length and cannot capture detailed technical documentation. Using names for documentation leads to overly long, unreadable names and does not scale for multiple elements.

B. OmniStudio components are self-documenting:
This is false. While OmniStudio provides a visual designer, the business logic and intent behind complex actions are not inherently obvious. Documentation is essential for future maintainability.

C. In a separate Word document stored on a shared drive:
This is an anti-pattern. External documentation becomes outdated quickly, is not versioned alongside the metadata, and is not accessible to all team members within the Salesforce environment. It fails governance requirements for traceability and currency.

References:

Salesforce OmniStudio Developer Guide → "Use the Description and Internal Notes fields to document the purpose and logic of OmniStudio components and their elements."

Explanation:

The requirements demand three distinct layouts (Open, Awaiting Closure, and Closed), each with a different set of fields, different visual styling (red, grey, and no border), and different actions (duplicate case link only for Closed).

In FlexCards, a state represents a complete configuration of the card's layout, data sources, fields, styling, and actions. When the required layouts and fields differ significantly between scenarios, using separate states is the recommended best practice because it:

Keeps each state clean and focused on its specific scenario.
Avoids complex conditional visibility logic cluttering a single view.
Makes the design easier to maintain and test.
Allows distinct visual treatments (borders) per state.

Since all cases are fetched by a single DataRaptor, the consultant can use that same data source across all three states, but configure each state to display only the relevant fields and apply the appropriate border styling.

Why other options are incorrect:

A. Using three FlexCards:
This is unnecessary and inefficient. It would require duplicating the data source configuration and increase maintenance overhead. A single FlexCard with multiple states is the intended pattern for this scenario.

C. Using a single FlexCard with multiple card filters:
Card filters are used to conditionally hide or show cards within a FlexCard canvas based on data values (e.g., show only Open cases). They do not support different field layouts, styling, or actions per case type—only visibility toggling.

D. Using a single FlexCard with three flyouts:
Flyouts are pop-up overlays triggered by user interaction (e.g., clicking a button). They are not designed to display a list of records with different layouts simultaneously. Flyouts are for supplementary information, not primary data display.

References:

Salesforce OmniStudio Developer Guide → "Use states in FlexCards to create different layouts for different scenarios, such as view, edit, and summary modes."

Trailhead: Build FlexCards → "States allow you to design completely different views within the same FlexCard, improving maintainability when layouts vary significantly."