✅ Explanation:

The root cause of the slow loading is that the Integration Procedure is fetching 50 fields but only five are displayed on the UI. This creates unnecessary overhead in multiple areas:

Larger SOQL query → increases query time and consumes more rows toward governor limits.
Larger JSON payload → increases network transfer time and browser memory consumption.
Slower parsing→ the FlexCard must parse and process unnecessary data.

The recommended optimization is to modify the Integration Procedure (or the DataRaptor it calls) to return only the five fields actually displayed. This reduces query complexity, shrinks the payload, and speeds up rendering without any functional loss. This aligns with the best practice of "fetch only what you need."

Why other options are incorrect:

A. Enable client-side processing on the FlexCard:
Client-side processing moves some logic to the browser, but it does not reduce the amount of data fetched. The 50 fields are still being transmitted and parsed—client-side processing would not solve the payload size issue.

B. Replace the Integration Procedure with a SOQL data source:
This is not recommended in OmniStudio. While SOQL is fast, Integration Procedures provide orchestration, error handling, and reusability that a raw SOQL data source cannot. The correct fix is to optimize the existing IP, not replace it entirely.

C. Increase the FlexCard timeout setting:
This addresses a symptom (timeout error) but not the root cause (slow data retrieval). Increasing the timeout would make the user wait even longer, worsening the user experience. The solution is to reduce the data being fetched, not increase the wait time.

🔗 References

Salesforce OmniStudio Developer Guide → "Optimize DataRaptors and Integration Procedures to return only fields needed by the consuming component."

Trailhead: Optimize FlexCard Performance → "Reduce the number of fields and records fetched to improve load times."

Explanation:

When two FlexCards are decoupled (separate child cards within a parent dashboard), they operate as independent components. However, business logic often requires them to react to changes in one another—such as refreshing "Recent Orders" when the shipping address changes in "Account Details."

The PubSub (Publish-Subscribe) model is the standard and recommended mechanism in OmniStudio for enabling cross-component communication between decoupled FlexCards. In this approach:

The "Account Details" card publishes an event (e.g., addressUpdated) after the address is updated.
The "Recent Orders" card subscribes to that event and, upon receiving it, triggers a refresh action (e.g., re-fetching data via its DataRaptor) to display updated shipping tax calculations.
This keeps the cards decoupled—they don't need to know about each other's internal structure—while still enabling reactive behavior. It also avoids heavy, platform-specific solutions like Apex events or manual refresh logic.

Why other options are incorrect:

A. Implement a full page reload after the address update:
This is heavy-handed and disruptive. A full page reload resets the entire UI state, causes unnecessary network traffic, and degrades user experience. Only the "Recent Orders" card needs to refresh—not the entire page.

C. Implement a Navigate action to reload the target card:
The Navigate action is used for navigation (e.g., redirecting to a URL or record page), not for refreshing a specific component. It cannot target and reload a decoupled child FlexCard in isolation.

D. Implement separate cards without cross-component communication:
This fails the requirement. If the "Recent Orders" card does not react to the address change, it will continue displaying stale tax calculations, delivering incorrect information to the agent.

🔗 References

Salesforce OmniStudio Developer Guide → "Use the PubSub model in FlexCards to enable loosely coupled components to communicate via events."

Explanation:

Calling 10 separate DataRaptors directly from the client-side browser creates excessive network round-trips, increases latency, and degrades user experience. The enterprise best practice is to consolidate these data requests into a single Integration Procedure that runs server-side.

An Integration Procedure can sequentially or in parallel call all 10 DataRaptors, aggregate their responses, and return a single combined JSON payload to the client-side OmniScript in one network call. This approach:

Reduces browser network traffic by minimizing the number of HTTP requests.
Improves performance by executing data operations closer to the database (server-side).
Enhances maintainability by centralizing data orchestration logic in one place.
Reduces client-side complexity and avoids potential CORS or security issues.

Why other options are incorrect:

B. Replace the Data Mappers with Apex classes called directly from the browser:
This is anti-pattern. Direct Apex calls from the browser (via @AuraEnabled) still require separate network calls per class and bypass the declarative benefits of OmniStudio. It also introduces custom code where OmniStudio's low-code tools are sufficient.

C. Keep the design as is, because client-side calls are always faster:
This is factually incorrect. Client-side calls are subject to network latency and browser overhead. Server-side execution (Integration Procedure) reduces round-trips and executes within the Salesforce data center, which is generally faster and more reliable.

D. Use a FlexCard to fetch the data and pass it to the OmniScript:
FlexCards are UI components for displaying data, not for orchestrating backend data retrieval for an OmniScript. While FlexCards can fetch data, they are not designed to be a backend data aggregation layer for an OmniScript—that is the role of Integration Procedures.

🔗 References

Salesforce OmniStudio Developer Guide → "Use Integration Procedures to orchestrate multiple DataRaptor calls, reducing network round-trips and improving performance."

✅ Explanation:

In a DataRaptor Load, the Default Value column in the Mapping tab is specifically designed to provide a fallback value when the source input is null or missing. By setting the Default Value to "Web" for the LeadSource field mapping, the DataRaptor will automatically apply that value during the load operation if no input value is provided. This is the declarative, built-in way to handle default values within the DataRaptor itself, keeping the logic self-contained and maintainable.

Why other options are incorrect:

A. Set the default value using a required validation rule in the Data Mapper:
Required validation rules are used to enforce that a value must be present—they do not supply a default value. Marking a field as required would cause the DataRaptor to fail if no value is provided, which is the opposite of the requirement.

B. Configure the field-level default value within Salesforce Object Manager:
While this would work for new records created outside of DataRaptors, it does not address the requirement within the DataRaptor itself. The DataRaptor's mapping takes precedence over object-level defaults, and this approach would not be visible or maintainable within the OmniStudio tooling.

C. Enable the fallback value property in the Data Mapper Options tab:
There is no "fallback value property" in the Options tab for DataRaptors. Default values are configured per-field in the Mapping tab, not globally.

🔗 References:

Salesforce OmniStudio Developer Guide → "Use the Default Value column in the DataRaptor Load Mapping tab to set a fallback value when the source field is null or missing."

Trailhead: Load Data with DataRaptors → "Default values ensure data integrity by providing a specified value when input is unavailable."

✅ Explanation:

To maintain a single logic base while supporting multiple languages, the most maintainable design is to create one OmniScript and leverage Salesforce Custom Labels for all user-facing text elements (labels, messages, picklist values). Salesforce Custom Labels are natively designed for translation—they support multiple languages and respect the user's language setting in their Salesforce profile.

This approach ensures that:

Logic remains identical across all languages, with no duplication of rules or branching.
Maintenance is simplified—changes to logic are made once, and translations are managed centrally in the Custom Labels interface (or via translation workbenches).
Scalability is built-in—adding a new language only requires adding a new translation for the custom labels, without touching the OmniScript itself.

Why other options are incorrect:

A. Use the Google Translate API in real time:
This is unreliable and insecure. Real-time translation requires external API calls, which can fail, introduce latency, violate data privacy, and incur unpredictable costs. It also cannot guarantee industry-specific terminology accuracy.

B. Create three separate OmniScripts:
This leads to massive duplication. Any change to the logic, such as adding a new question or modifying a validation rule, must be replicated across three scripts, increasing maintenance effort and risk of inconsistencies.

C. Use a Data Mapper to fetch translated text from a custom object:
While possible, this is overly complex. Custom objects for translations require manual data management, caching considerations, and additional SOQL queries. Custom Labels are the built-in, declarative, and performance-optimized solution for this exact requirement.

🔗 References

Salesforce Custom Labels Documentation → "Custom labels are custom text values that can be accessed from Apex classes, Visualforce pages, Lightning components, and OmniScripts. They support translation and are language-aware."