✅ Explanation:

The requirement calls for a standalone page that:
Is accessible from the App Launcher.
Is not tied to a specific record.
Displays a parent FlexCard with account details and a child FlexCard with related contacts.

An App Page (Lightning App Page) is the correct choice because it is a standalone, record-agnostic page that can be added to the Salesforce navigation menu and launched directly from the App Launcher. It is designed to host Lightning components—including FlexCards—without requiring a record context. This makes it ideal for dashboards, workspaces, and overview pages that aggregate data from multiple sources.

Why other options are incorrect:

A. Email Application Pane:
This is a specialized UI component used within the Salesforce Email application for email-related interactions. It is not designed for hosting FlexCards or serving as a standalone page accessible from the App Launcher.

B. Record Page:
Record pages are record-specific—they display data for a single Salesforce record (e.g., an Account) and require a record ID in the URL. The requirement explicitly states the page is "not tied to a specific record," making Record Page unsuitable.

C. Home Page:
While Home Pages are record-agnostic and accessible from the App Launcher, they are typically limited to the Home tab and may have restrictions on the types of components that can be placed there. App Pages offer greater flexibility for custom standalone pages.

🔗 References:

Salesforce Lightning Experience Documentation → "App Pages are custom Lightning pages that can be added to the app navigation menu and accessed from the App Launcher. They are not tied to a specific record."

✅ Explanation:

The requirement is to output a specific, nested JSON structure: { "CaseDetails" : { "Info" : [...]}}. The Output Mapping tab in a Data Mapper (DataRaptor Extract) is where you define the exact structure of the output JSON. Using colon (:) notation in the Output JSON Path fields, you can construct a custom nested hierarchy that differs from the source Salesforce object structure.

For example, to build the required structure, you would map a field from your Salesforce query to an Output JSON Path like CaseDetails:Info:CaseNumber. This tells the Data Mapper to place that field under Info, which is nested within CaseDetails—precisely achieving the nested format requested.

Why other options are incorrect:

A. Use a Data Mapper Transform to build the hierarchy after the extraction:
A Transform Data Mapper is used to reshape or manipulate data after extraction. While it could theoretically build a hierarchy, the Output Mapping tab of the primary Extract Data Mapper is the intended and most direct method for defining the final output structure. Using a separate Transform adds unnecessary complexity for this specific requirement.

B. Use a Formula to construct the JSON string manually:
Formulas are used for calculations and simple data manipulation, not for manually constructing complex JSON hierarchies. They are meant to compute values (e.g., SUM(Products:Price)), not to rebuild entire structural relationships.

C. The JSON structure is automatically determined by the Salesforce object structure and cannot be changed:
This is incorrect. A key purpose of Data Mappers is to allow consultants to design the output structure to meet business needs, free from the constraints of the underlying data model. The Output Mapping tab exists explicitly to customize the output JSON.

🔗 References:

Salesforce Help: Omnistudio Data Mapper Overview → "Data Mapper also enables administrators and developers to easily move data between Salesforce objects and the JSON data structures used in OmniScript. It provides a translation capability that frees designers from the constraints of the underlying data structure".

Explanation:

The requirement is to control pages or groups of fields based on user choices—this is exactly what the Conditional View property is designed for. Conditional View allows you to dynamically show or hide entire Steps (pages) or Blocks (groups of fields) within an OmniScript based on data values or expressions evaluated at runtime.

For example, if a user selects "Business" as account type, a Step containing business-specific fields becomes visible; if they select "Individual," a different Step appears. This provides a clean, user-friendly experience by showing only relevant content without cluttering the interface with unnecessary fields.

Key distinction:Conditional View controls visibility of entire containers (Steps/Blocks), not individual elements.

Why Other Options Are Incorrect

A. Use the Visibility Rules property on a Step or Block element:
There is no property called "Visibility Rules" on Steps or Blocks in OmniScript. The correct property name is Conditional View. This is a distractor option.

B. Create child OmniScripts for branched flow:
While child OmniScripts can handle branched logic, they are used for modularizing complex processes (e.g., reusable sub-processes) and are overkill for simply showing/hiding pages or groups of fields. Conditional View is the simpler, intended solution for dynamic visibility.

D. Use the Radio Input property on a Step or Block element:
Radio Input is a property of individual elements (like Radio buttons) to define display style—it has nothing to do with controlling visibility of entire Steps or Blocks.

🔗 References

Salesforce OmniStudio Developer Guide → "Use the Conditional View property on Steps and Blocks to dynamically show or hide sections of an OmniScript based on data values."

Trailhead: Build OmniScripts→ "Conditional View allows you to control which pages or groups of fields appear based on user selections, creating a dynamic and personalized experience."

Explanation:

The Standard OmniStudio runtime is now built directly into the Salesforce Platform, not delivered as a separate managed package. This means it receives updates automatically as part of Salesforce's thrice-yearly seasonal releases, directly aligning with the client's policy of using platform-native features that minimize manual maintenance.

Why other options are incorrect:

A. Custom-built runtime using unlocked packages: This contradicts the requirement entirely. A custom solution would require significant manual maintenance and would not receive automatic Salesforce updates.

C. OmniStudio Managed Package: The managed package uses a "pull" model, requiring customers to manually manage and schedule upgrades—this does not meet the automatic update requirement.

D. Managed Package with automated installation script: Even with automation, managed packages still require manual oversight and planning, and do not receive updates seamlessly with Salesforce's core releases.

🔗 References

Salesforce Developers Blog: "OmniStudio is a native, deeply integrated part of the Salesforce Platform. Once you enable your industry license... the designers and runtime are available immediately. There’s no need to rely on packages, so you’re always using the fastest and latest version."

Explanation:

Integration Procedures are server-side orchestration engines purpose-built for complex backend logic. They excel at chaining multiple external API calls, applying conditional logic, handling errors, and performing complex JSON transformations using DataRaptors and Set Values—all without writing Apex. This makes them the ideal choice when the scenario involves multi-step orchestration with intricate data manipulation. Unlike Salesforce Flow, Integration Procedures provide native support for JSON parsing, mapping, and transformation through declarative actions, significantly reducing development effort and maintenance overhead.

Why other options are incorrect:

A. Restrict JSON handling:
This is the opposite of reality. Integration Procedures are designed to enable and simplify complex JSON transformations, not restrict them. They provide native JSON parsing and mapping capabilities through DataRaptors.

C. Require HTTP callouts exclusively:
Integration Procedures are not limited to HTTP callouts. They can also call DataRaptors, execute calculations, invoke Apex methods, and perform other server-side actions. HTTP callouts are just one of many capabilities.

D. Execute entirely on the client side:
This is factually incorrect. Integration Procedures execute entirely on the server side (Salesforce platform). Client-side execution is the domain of OmniScripts, which run in the browser. Integration Procedures are server-side only.

References:

Salesforce OmniStudio Developer Guide → "Integration Procedures are server-side orchestration tools that execute complex business logic, including HTTP callouts, DataRaptor operations, and JSON transformations."