Explanation:

Let’s break down the requirements and match them to the appropriate OmniScript elements:

1. Select one payment method from a list of options
What’s needed: The user must pick one payment method from a list, like choosing “Credit Card,” “PayPal,” or “Bank Transfer.” In OmniScript, this is typically done with a dropdown or radio button interface where only one option can be selected.

Correct Element: Radio (A)
The Radio element displays a list of options as radio buttons, allowing the user to select exactly one option. It’s ideal for presenting a small, predefined list of payment methods in a clear, visual way.
For example, the OmniScript could show radio buttons labeled “Credit Card,” “PayPal,” and “Bank Transfer,” and the user clicks one.

Why not others?

Multi-Select (B): This element allows users to choose multiple options, which doesn’t fit since the requirement is to select one payment method.

Select (D): The Select element creates a dropdown menu, which could work, but Radio is a valid choice in OmniScript for single-selection lists, especially for visual clarity with fewer options. Since Radio is in the correct answer set, it’s the intended choice here.

Checkbox (C): Checkboxes allow multiple selections, so they’re not suitable for choosing one payment method.

2. Enter address information with autocomplete
What’s needed: The user needs to input an address, and the autocomplete feature should help by suggesting valid addresses as they type (e.g., using a service like Google Maps). In OmniScript, autocomplete for addresses is handled by a specific element designed for this purpose.

Correct Element: TypeAhead (A)
The TypeAhead element provides autocomplete functionality, allowing users to type an address and see real-time suggestions from a configured data source (e.g., an external address API). It’s perfect for streamlining address entry and ensuring accuracy.
For example, as the user types “123 Main,” TypeAhead might suggest “123 Main St, Springfield” based on API results.

Why not others?
Address (B): The Address element is used to capture address components (e.g., street, city, state) in separate fields, but it doesn’t natively support autocomplete unless paired with a data source. TypeAhead is specifically designed for autocomplete functionality.

Geolocation (C): This element captures geographic coordinates (latitude and longitude), often from a user’s device, not for entering addresses with autocomplete.

3. Enter a phone number
What’s needed: The user must input a phone number, and the element should ensure the input is formatted correctly for phone numbers (e.g., (123) 456-7890). Correct Element: Telephone (A)
The Telephone element is designed specifically for capturing phone numbers. It includes formatting and validation to ensure the input matches a phone number format, making it user-friendly and accurate.
For example, the user types “1234567890,” and the Telephone element formats it as “(123) 456-7890.”

Why not others?

Number (C, D): The Number element is for capturing numeric values, like quantities or amounts (e.g., 42), but it doesn’t provide specific formatting or validation for phone numbers, which often include parentheses, dashes, or country codes.

Why the Other Options Are Incorrect:

B. Multi-Select, Address, Telephone:
Multi-Select is wrong because it allows multiple selections, not one payment method. Address lacks native autocomplete, unlike TypeAhead. Telephone is correct but not enough to make this option right.

C. Checkbox, Geolocation, Number:
Checkbox allows multiple selections, not one. Geolocation is for coordinates, not address autocomplete. Number doesn’t handle phone number formatting.

D. Select, TypeAhead, Number:
Select could work for payment methods (dropdown), but Radio is in the correct answer set and is a valid OmniScript choice. TypeAhead is correct for address autocomplete. Number is incorrect for phone numbers, as Telephone is the specialized element.

Summary:
To capture the required information in the OmniScript:
→ Use Radio to let the user select one payment method from a list.
→ Use TypeAhead for entering an address with autocomplete.
→ Use Telephone for entering a properly formatted phone number.
→ The correct answer is A. Radio, TypeAhead, and Telephone.

Explanation

The health provider company needs to display medical test reports (a custom object related to the Patients object) for each patient, showing fields like report name, date requested, and date generated, with the ability to perform three actions (Approve, Print for Review, Send for Retest) per report. OmniStudio tools, such as FlexCards and OmniScripts, are well-suited for creating a modern, user-friendly interface with actionable functionality.

Let’s evaluate the options:

Single FlexCard with multiple actions (D):

Why it fits: A FlexCard is ideal for displaying data in a concise, customizable format, such as a list of medical test reports for a patient. The FlexCard can use a Data Table or Repeat Block to dynamically display the required fields (report name, date requested, date generated) for each medical test report, retrieved via a DataRaptor Extract Action querying the Medical Test Report custom object related to the Patient record. The FlexCard can include multiple Actions (e.g., buttons or links) for each report to trigger the required actions:

Approve: An Action invoking an OmniScript or Integration Procedure to update the report’s status (e.g., set a Status field to "Approved").

Print for Review: An Action triggering a process to generate a printable report, possibly via an OmniScript or Integration Procedure that formats data for printing.

Send for Retest: An Action invoking an OmniScript or Integration Procedure to initiate a retest request, potentially updating fields or creating a new record.

The FlexCard can be embedded in a Lightning page or Experience Cloud site, providing a 360° view of the patient’s reports with actionable buttons for medical officers. This solution is efficient, scalable, and aligns with OmniStudio’s declarative design capabilities, meeting all requirements in a single, cohesive interface.

How it works: In the FlexCard Designer, configure a Data Table or Repeat Block to display medical test report records, with a DataRaptor Extract to fetch data (e.g., SELECT Name, Date_Requested__c, Date_Generated__c FROM Medical_Test_Report__c WHERE Patient__c = :patientId). Add Action elements (e.g., buttons) for Approve, Print for Review, and Send for Retest, each linked to an OmniScript or Integration Procedure for processing.

Salesforce list view with custom buttons/links (A):

Why it’s incorrect: While a Salesforce list view can display medical test reports with custom buttons or links (created via Lightning App Builder or custom code), it is not an OmniStudio tool and lacks the advanced customization and integration capabilities of FlexCards. List views are limited to standard Salesforce UI patterns and don’t support complex, guided processes or external system integrations as seamlessly as OmniStudio. Additionally, custom buttons/links may require more custom code (e.g., Apex, Visualforce) to implement actions like Print for Review or Send for Retest, making it less efficient than a declarative OmniStudio solution.

Multiple FlexCards with single action (B):

Why it’s incorrect: Creating multiple FlexCards, each with a single action, is inefficient and unnecessary. A single FlexCard can handle multiple actions per record (Approve, Print for Review, Send for Retest) using a Data Table or Repeat Block. Multiple FlexCards would lead to redundant configurations, increased maintenance, and a fragmented user experience, as users would need to navigate multiple cards for the same patient’s reports. This approach doesn’t align with the requirement for a unified view of all reports with multiple actions.

OmniScript with multiple Step elements (C):

Why it’s incorrect: OmniScripts are designed for guided, interactive processes (e.g., wizards for data entry or updates), not for displaying lists of records with actions. While an OmniScript could be used to handle the actions (e.g., Approve, Print, Retest), it’s not suited for displaying a dynamic list of medical test reports in a tabular or card-based format. Using multiple Step elements to list reports would be cumbersome and non-intuitive, as OmniScripts are sequential and process-oriented, not optimized for data presentation like FlexCards.

Recommended Solution

Create a single FlexCard to display medical test reports for a patient, using a Data Table or Repeat Block to list records with fields: report name, date requested, and date generated.

Configure a DataRaptor Extract Action to fetch Medical Test Report records related to the Patient (e.g., SELECT Name, Date_Requested__c, Date_Generated__c FROM Medical_Test_Report__c WHERE Patient__c = :patientId).

Add multiple Actions to the Data Table or Repeat Block:

Approve: Triggers an OmniScript or Integration Procedure to update the report’s status (e.g., Status__c = 'Approved'). Print for Review: Invokes an OmniScript or Integration Procedure to generate a printable report, potentially using a DataRaptor Transform to format data or a REST API to a printing service.

Send for Retest: Launches an OmniScript or Integration Procedure to create a retest request, updating fields or creating a new record (e.g., Retest_Requested__c = true or a new Medical Test Report record).

Embed the FlexCard in a Lightning page or Experience Cloud site for medical officers to access within the application.

Optionally, use Conditional Visibility or States to filter reports (e.g., show only pending reports) or style the UI based on report status. This solution leverages FlexCards’ strengths for data display and actionability, ensuring a clean, efficient interface that meets all requirements.

References

Salesforce Help: Create a Flexcard (Managed Package) – Explains configuring FlexCards with Data Tables or Repeat Blocks to display related records and add multiple actions.

Trailhead: OmniStudio FlexCards – Covers using FlexCards for data presentation and triggering actions like OmniScripts or Integration Procedures.

Salesforce Help: Add Actions to a FlexCard – Details how to configure multiple actions (e.g., buttons) to invoke processes for tasks like approving or printing.

Salesforce Help: Omnistudio Data Mapper Extract Action (Managed Package) – Describes retrieving related records (e.g., Medical Test Reports) for display in a FlexCard.

Explanation

The question requires matching three specific data capture needs with the most appropriate OmniScript Element.

Let's break down each requirement and why the chosen elements are the best fit:

"Select one payment method from a list of options"

Requirement: The user must choose only one option from a predefined list.

Correct Element: Radio

Why: A Radio button group is the standard UI element for presenting a list of mutually exclusive options where only one selection is allowed. This perfectly fits the "select one" requirement for a payment method (e.g., Credit Card, PayPal, Bank Transfer).

Why not the others?

Multi-Select (Option B) is for choosing multiple options, which violates the "select one" rule.

Checkbox (Option C) is typically for enabling/disabling a single option or, when grouped, for multi-selection.

Select (Option D) could technically work as a dropdown, but a Radio group provides a better user experience by showing all options at once, making it clearer that only one can be chosen.

"Enter the address information with autocomplete"

Requirement: The user should start typing an address and have the system suggest complete, validated addresses.

Correct Element: TypeAhead

Why: The TypeAhead element is explicitly designed for this purpose. It provides real-time suggestions from a data source (like an address validation service) as the user types, improving accuracy and speed. The standard Address element (Option B) might not always have robust autocomplete functionality and is often a collection of individual fields (street, city, zip).

Why not the others?

Address (Option B) is a composite element for breaking down an address into its parts but lacks the specific "autocomplete" behavior described.

Geolocation (Option C) is used to capture a user's current geographical coordinates, not for manually entering a street address with suggestions.

"Enter a phone number"

Requirement: Capture a phone number.

Correct Element:Telephone

Why: The Telephone element is a specialized input field for phone numbers. It often includes built-in validation for correct phone number formats (digits, length, etc.) and can be configured for international formats. This provides a better, more validated user experience than a simple number field.

Why not the others?

Number (Options C and D) is a generic element for numerical values. It would accept any number (like 100, 3.14, etc.) and does not provide any phone number-specific formatting or validation.

Summary

The combination of Radio (for single selection), TypeAhead (for address with autocomplete), and Telephone (for a validated phone number) directly and precisely matches the business requirements outlined in the question.

Reference:

These element types and their specific use cases are defined in the Salesforce OmniStudio Documentation and are a core part of the "Build Industries-First Applications with OmniStudio" trailhead.

Explanations:

A. They future-proof your front-end design.

An Integration Procedure (IP) acts as a middleware or service layer between your front-end (FlexCard/OmniScript) and your data sources (Salesforce, external systems, etc.). By using an IP, you decouple the front-end logic from the back-end data retrieval and processing logic. If the underlying data source changes (e.g., you switch from a SOQL query to an Apex callout, or you modify a formula), you only need to update the Integration Procedure. The FlexCard or OmniScript that uses the IP remains unchanged. This makes your solution more modular, maintainable, and "future-proof."

C. They combine multiple actions into a single server call.

A FlexCard or OmniScript can use DataRaptors, Calculation Procedures, and other actions individually as data sources. However, if you use them separately, each one would require a separate call to the server, leading to multiple round trips and slower performance. An Integration Procedure allows you to chain these actions together in a specific sequence. The entire procedure—all its steps—is executed in a single server call. This significantly improves performance and user experience, especially in mobile or high-latency networks.

Why the Other Options are Incorrect:

B. They can retrieve Salesforce data from multiple objects faster. While IPs can retrieve data from multiple objects, this is not their primary, defining advantage. A well-designed DataRaptor Turbo can also be very fast. The speed benefit of an IP comes primarily from combining actions into one call (point C), not from an inherent speed advantage in data retrieval itself.

D. They enable better usability in digital interactions. Usability is primarily driven by the front-end design of the OmniScript or FlexCard (layout, guidance, error handling). While the performance gained from using an IP (single server call) contributes to a better user experience by making it faster, "better usability" itself is a result of the front-end design, not a direct reason to choose an IP as a data source.

Reference:

This concept is core to the OmniStudio design philosophy. The official Salesforce OmniStudio Developer Guide and preparation materials for the OmniStudio Developer certification emphasize the use of Integration Procedures as a best practice for creating efficient, scalable, and maintainable solutions by promoting loose coupling and reducing client-server round trips.

Explanation:

The proposed design is one huge OmniScript with 25+ steps and multiple branching paths for different sales processes. That goes against OmniScript best practices because:

➡️ OmniScripts should be modular, maintainable, and easy to use.
➡️ Having too many steps and branches makes the script hard to maintain and slows down performance.
➡️ Each business process (Change of Plan, New Sale, Loyalty) has its own unique flow, so it’s best to separate them into individual OmniScripts.

Then, you can use a parent script, a launcher, or FlexCard actions to decide which OmniScript to run based on the sale type.

Why the other options are incorrect:

A. Pass the process type as an input parameter
This only controls which path to follow, but it doesn’t solve the complexity and maintenance issues of having one giant OmniScript.

B. Add more conditional views to branch the OmniScript into logical sections
Conditional views help with visibility, but they don’t address the fundamental problem: the OmniScript is too large and complex.

C. Add more Step elements to create shorter pages
Steps improve page design, but the underlying script is still too long and complicated. It doesn’t fix the maintainability issue.

D. Create a specific OmniScript for each business process
✅ This is the recommended approach. Smaller, focused OmniScripts are easier to maintain, test, and extend.

✅ Exam Tip:
If an OmniScript design seems too big, too branched, or hard to maintain, the best practice is to break it down into smaller OmniScripts for each process and reuse them where needed.