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.

Explanation

The recommended design leverages the core capabilities of FlexCards for displaying related, diverse data and enabling user interaction.

Parent FlexCard:
Serves as the main container and entry point, typically based on the main object (the Account). Provides the 360° view of the customer.

Child FlexCards:
Used to display distinct, related data sets fetched from the same or different data sources (the Integration Procedure).Displays Active Opportunities and Active Contracts as separate, dedicated sections.

Card Actions:
Interactive elements (buttons, links) added to a Card that trigger actions like launching an OmniScript, running another Integration Procedure, or navigating a page.Provides the ability to view and renew contracts (e.g., a "Renew" button on the Contract Child FlexCard).

Why Other Options Are Incorrect:

B & C. Different Card States:
Card States are used to change the content/layout of a single Card based on its data (e.g., showing a different state if a contract is "Active" vs. "Expired"). They are not the best way to display entirely different sets of related records (Opportunities and Contracts) that should live side-by-side on the console.

C & D. Single Child:
Using only a single Child FlexCard would be insufficient, as the requirements call for two distinct lists of related records: Opportunities and Contracts. Each distinct list needs its own dedicated Child FlexCard for clarity and organization.

C. Single Child and multiple Card States:
This would be overly complex and confusing, trying to cram distinct data (Account, Opportunities, Contracts) into one card that changes its look based on data.

D. Parent FlexCard with single Child and Card Actions:
Fails because it doesn't account for the need to display the Opportunities and Contracts as separate, related lists.

Reference (Salesforce Industries/OmniStudio)

This question relates to FlexCards within OmniStudio (formerly Vlocity/Salesforce Industries).

Parent/Child Cards are the standard way to build a hierarchical 360° view, where the Parent Card is the main record (Account) and Child Cards display related lists (Opportunities, Contracts).

Actions (Card Actions) are essential for enabling user interaction, such as the "view and renew contracts" requirement.

Explanation

To meet the requirement of displaying an account and its associated contacts with varying numbers, along with specific display and interaction features, the consultant should recommend the following FlexCard features:

Data table (A):

A Data table element in FlexCards is ideal for displaying a list of records, such as contacts associated with an account. It can dynamically show fields like First Name, Last Name, Email, and Phone Number in a tabular format. The Data table supports Actions, which can be configured to enable editing contact information or sending a message (e.g., via OmniScript or Integration Procedure triggers). Additionally, styling options in the FlexCard Designer allow the primary contact to be highlighted with a blue border by applying conditional formatting based on a field (e.g., a "Primary Contact" boolean or specific logic in the data source).

Why it fits: The Data table handles dynamic lists and supports interactivity (edit/message actions) and conditional styling for the primary contact.

Repeat Block (D):

A Repeat Block (also called a Repeating Block) is used to iterate over a list of records, such as contacts, and render them as individual elements or cards within the FlexCard. Each contact can be displayed with fields (First Name, Last Name, Email, Phone) and include actionable buttons for editing or messaging. Conditional styling can be applied within the Repeat Block to highlight the primary contact with a blue border using style rules (e.g., based on a "Primary Contact" field value).

Why it fits: Repeat Blocks are perfect for rendering variable numbers of records in a customizable, non-tabular format, with support for actions and styling.

Why Other Options Are Incorrect:

B. Flyouts:

Flyouts are used to display additional details or actions in a pop-up/modal when a user interacts with an element (e.g., clicking a contact). While Flyouts could be used for editing or messaging, they are not ideal for displaying the initial list of contacts or applying a blue border to the primary contact, as they are secondary interactions rather than the primary display mechanism.

C. States:

States in FlexCards control conditional visibility or behavior of elements based on data or business logic (e.g., showing different fields for active vs. inactive accounts). They are not suited for iterating over a dynamic list of contacts or applying styling like a blue border to a specific record. States could be used for other purposes (e.g., switching between account types), but they don’t address the core requirement of displaying and styling a variable contact list.

How These Features Work Together:

The Data table is better for a structured, tabular display of contacts with consistent columns and built-in action buttons.

The Repeat Block offers more flexibility for a card-based or custom layout, where each contact is rendered as a separate visual block with tailored styling.

Either can fulfill the requirement, but the choice depends on the desired UI (table vs. card layout). Both support actions for editing/messaging and conditional styling for the primary contact’s blue border.

References

Salesforce Help: Add a Data Table to a FlexCard – Describes using Data tables for dynamic record lists with actions and conditional styling.

Salesforce Help: Add a Repeating Block to a FlexCard – Explains how Repeat Blocks iterate over record sets and support custom layouts and actions.

Trailhead: Style FlexCard Elements – Covers applying conditional styling (e.g., blue border) based on data conditions in Data tables or Repeat Blocks.

Explanation

This question is about dynamically changing the interface and available actions based on the value of a record's field—in this case, the Case Status.

Let's break down the requirement:

The core need: The "Reopen Case" button should be visible and clickable only when the Case Status is "Closed". It must be hidden or disabled when the status is "Active" or "Escalated".

The underlying concept: This is a classic example of needing to change the behavior and appearance of the FlexCard based on data conditions.

Here is why State is the correct and most powerful solution:

What is a State? In a FlexCard, a State allows you to create multiple, distinct "views" or "versions" of the same card. You define a condition (e.g., Status EQUALS Closed) to determine when each state is active.

How it solves the problem:

You would create a state named "Closed State" with a condition 'Status' == 'Closed'.

Within this "Closed State," you would add the "Reopen Case" button as a clickable element.

The Default State of the card would have the same layout but would not include the "Reopen Case" button.

The FlexCard engine automatically evaluates the record's status and displays the correct state, showing the button only for closed cases.

Why the Other Options Are Incorrect:

A. Conditional View: While this sounds similar, a "Conditional View" is not the primary, named feature for this specific use case in FlexCards. "State" is the formal and most robust mechanism for creating entirely different layouts and action sets based on data. Conditional View might refer to simpler visibility toggles, but State is the comprehensive solution.

B. Flyouts: Flyouts are used for displaying additional, related information in a pop-out panel (e.g., showing case history). They do not control the conditional visibility of a primary action button on the card itself based on a record's field value.

D. Styling: Styling controls the visual appearance (colors, fonts, borders) of elements. You could, for example, use conditional styling to gray out a button, but it cannot be used to add or remove the "Reopen Case" action from the card's logic and layout. The requirement is about functionality (having the option), not just appearance.

Summary / Key Takeaway:

The State functionality in FlexCards is explicitly designed for this purpose: to present different user interfaces, including different sets of actionable buttons, depending on the data context of the record being displayed. It is the most direct and powerful way to meet the requirement of showing a "Reopen" button only for Closed cases.

Reference:

This is a fundamental concept in OmniStudio. The use of Card States to dynamically show/hide elements based on record data is covered in the "FlexCards" module of the OmniStudio Trailmix and official documentation.

Explanation

The Step element is the fundamental UI container in an OmniScript (part of Salesforce OmniStudio).

Organizes into Pages: The primary purpose of the Step element is to break a long business process into manageable pages or screens. When a user completes a Step (by clicking "Next"), they move to the next page defined by the subsequent Step element. This makes complex processes less overwhelming and improves the user experience.

Navigation: All elements (Input Fields, Actions, Blocks, etc.) must be placed inside a Step. Steps inherently contain the standard navigation buttons (Next and Previous), which manage the flow and movement between these pages.

Why the Other Options are Incorrect:

B. Groups elements that extract data: This is the purpose of an Action Block, which runs multiple Actions (like DataRaptors or Integration Procedures) in parallel, or simply the purpose of the Action elements themselves.

C. Enables the use of repeatable blocks: This is the function of a Block element when its Repeatable property is checked.

D. Allows the user to input data: This is the purpose of Input Elements (like Text, Select, Checkbox) which are placed inside a Step. The Step itself is the container, not the field for input.

Reference (Salesforce OmniStudio)

The Step element is essential for defining the stages of an OmniScript. Salesforce documentation confirms that each Step presents a page to the user and manages the navigation flow.

Explanation

To meet the insurance company’s requirement of creating an OmniScript that allows users to review and edit account details (website and phone number) with each field displayed on a separate line, the consultant should include the following OmniScript elements:

Telephone (C):

The Telephone element is specifically designed for capturing and validating phone numbers. It ensures the input adheres to standard phone number formats (e.g., with country codes or specific patterns) and provides built-in validation, making it ideal for the account phone number field.

Why it fits: This element is tailored for phone number input, ensuring proper formatting and user-friendly data entry for the phone number requirement.

Line Break (D):

The Line Break element is used in OmniScript to separate fields visually, ensuring each field (website and phone number) appears on a separate line in the UI. This element explicitly controls the layout to meet the requirement of displaying fields on separate lines.

Why it fits: The Line Break element directly addresses the layout requirement by forcing each field to render on a new line, enhancing clarity and user experience.

Text (E):

The Text element is used for capturing general text input, such as a website URL. It allows users to enter and edit free-form text, making it suitable for the company’s website field, which typically requires a string input (e.g., "www.example.com").

Why it fits: The Text element is appropriate for capturing and displaying the website field, as it supports flexible text input without specific formatting constraints beyond optional validation rules.

Why Other Options Are Incorrect:

A. Number:

The Number element is designed for numeric input (e.g., integers or decimals) with specific formatting options, such as currency or percentages. A phone number, while containing digits, is treated as a string with specific formatting (e.g., hyphens, parentheses), making the Telephone element more appropriate. Similarly, a website URL is text-based, not numeric.

B. Text Area:

The Text Area element is used for multi-line text input, such as comments or descriptions. A website URL is typically a single-line input, so the Text element is more suitable. Using a Text Area would be unnecessary and could confuse users expecting a single-line field for a URL.

How These Elements Work Together:

The Text element captures the website URL (e.g., "www.example.com").
The Telephone element captures and validates the account phone number (e.g., "+1-123-456-7890").
The Line Break element ensures each field is displayed on a separate line in the OmniScript UI, meeting the layout requirement.
In the OmniScript Designer, these elements are placed within a Step or Block, with Line Breaks inserted between the Text and Telephone elements to control the layout declaratively.

References

Salesforce Help: OmniScript Element Types – Details the Telephone, Text, and Line Break elements, including their use cases for input and layout control.

Trailhead: Build an OmniScript – Explains how to configure input elements like Text and Telephone and use Line Break for layout.

Salesforce Help: Design OmniScripts for User Input – Covers best practices for selecting elements like Text for URLs and Telephone for phone numbers, with layout considerations.

Explanation

This question focuses on the specific use case of creating a new record directly from a FlexCard interface. The key phrase is "the user should be able to create a new case from the canvas."

Let's analyze the requirement and why "Blank Card State" is the correct choice:

The Scenario: You have a FlexCard displaying a list of cases for an account. This is the "read-only" or "display" view. To create a new case, you need a different interface—a form with empty fields for the user to fill out.

What is a Blank Card State? A Blank Card State is a special state in a FlexCard that is not tied to any specific data record. It acts as an empty template or a blank form. Its primary purpose is to allow users to create brand new records.

How it Solves the Problem:

The consultant would design the main FlexCard to display existing cases (using Active Card States or a List Card).

They would add a "New Case" button somewhere on the interface.

This button would be configured to navigate to the Blank Card State.

The Blank Card State would contain all the necessary input elements (like Text, Textarea, Picklist, etc.) for the user to enter the details of the new case.

Once the user fills out the form and submits it, the FlexCard would create the new Case record and then typically refresh to show the updated list, including the newly created case.

Why the Other Options Are Incorrect:

A. Active Card State: An Active Card State is used to display data from an existing record. It is "active" because it is bound to a specific record in the database. It is perfect for showing the list of existing cases but cannot be used as a template to create a new record from scratch.

C. Edit Mode State: An Edit Mode State is used to edit the data of an existing record. You first have an Active Card State showing the data, and then you can switch to an Edit Mode State to modify that same record. It is not designed for creating net-new records.

D. New Card State: This is a distractor. While it sounds correct, "New Card State" is not a standard, named state type in FlexCards. The official term for the state used to create new records is the Blank Card State.

Summary / Key Takeaway:

The Blank Card State is the fundamental and purpose-built tool within FlexCards for enabling "create new record" functionality. It provides the empty form that allows users to input data for a record that does not yet exist in the database.

Reference:

This is a core concept for FlexCard development. The distinction between Active, Edit, and Blank states is covered in the "Get to Know FlexCards" module on Trailhead and the official OmniStudio documentation.

Explanation

The Loop Block is the essential feature in a Salesforce OmniStudio Integration Procedure (IP) used to iterate over a list or array of data and perform a series of actions (including multi-step calculations) on each item.

Iteration: You configure the Loop Block to target the list of contacts (the data array).

Execution: For every contact record in that list, the Loop Block executes the steps (Actions and other Blocks) contained inside it.

Multi-Step Calculation: Inside the Loop Block, you would place:

One or more Set Values actions using formulas to perform calculations.

A Calculation Action (calling an Expression Set or Calculation Procedure) to handle complex, multi-step math on the current contact's data.

A DataRaptor Load Action or Update Action to save the final calculated value back to the contact record.

Why the Other Options are Incorrect:

B. Batch Action: There is no standard "Batch Action" element in an Integration Procedure. Batching typically refers to asynchronous Apex processing for large data volumes, which is separate from the IP's synchronous flow control.

C. Conditional Block: This block is used for executing steps conditionally (based on a true/false evaluation) but does not handle repetition or iteration over a list.

D. DataRaptor Transform Action: This is a powerful tool for manipulating (re-shaping, merging, aggregating) JSON data in bulk, but it cannot execute a multi-step, sequential business process or calculation on each item in the same way a Loop Block can. While it can perform some aggregations, a Loop Block is necessary to run a full multi-step process for each record.

Reference (Salesforce OmniStudio)

The Loop Block property allows an Integration Procedure to process arrays, repeating all the actions contained within the block for every item in the list.

Explanation

The requirement is to identify an OmniScript element that can retrieve data from multiple sources. Let’s evaluate each option:

Integration Procedure Action (B):

An Integration Procedure Action in OmniScript is designed to execute an Integration Procedure, which can aggregate data from multiple sources, such as Salesforce objects (via DataRaptors), external systems (via REST/SOAP APIs), or other data transformations. Integration Procedures allow you to combine and manipulate data from various sources into a single JSON response, making this the ideal element for retrieving data from more than one source.

Why it fits: Integration Procedures are specifically built to handle complex data operations, including fetching and combining data from multiple sources (e.g., Salesforce and external legacy systems) in a single action.

Calculation Action (A):

A Calculation Action performs mathematical or logical operations on data already available within the OmniScript (e.g., summing values or concatenating strings). It does not retrieve data from external or multiple sources; it only manipulates existing data.

Why it’s incorrect: It lacks the capability to fetch data from any source, let alone multiple sources.

DataRaptor Extract Action (C): A DataRaptor Extract Action retrieves data from a single Salesforce object or related objects using a SOQL query or predefined mapping. While powerful for Salesforce data, it is limited to a single data source (Salesforce) and cannot natively combine data from external systems or multiple disparate sources without additional configuration.

Why it’s incorrect: DataRaptor Extract is restricted to one Salesforce-based data source per action, unlike Integration Procedures.

Matrix Action (D):

A Matrix Action is not a standard OmniScript element in Salesforce OmniStudio. The term may refer to Vlocity’s legacy Matrix Calculations or custom configurations, but it is not used for data retrieval from multiple sources. Even in legacy contexts, Matrix Actions were for calculations, not multi-source data fetching.

Why it’s incorrect: It’s either a distractor or irrelevant to OmniScript’s data retrieval capabilities.

Why Integration Procedure Action Stands Out:

Integration Procedures can orchestrate multiple data operations, such as calling multiple DataRaptors, invoking REST/SOAP APIs for external systems, or performing transformations, all within a single action. This makes them uniquely suited for retrieving and combining data from multiple sources (e.g., Salesforce objects, external APIs, or even static data).

In the OmniScript, the Integration Procedure Action references an Integration Procedure, which outputs a unified JSON response that OmniScript elements can use to display or process data.

References

Salesforce Help: Integration Procedures – Explains how Integration Procedures aggregate data from multiple sources, including Salesforce and external systems.

Trailhead: OmniStudio Integration Procedures – Details using Integration Procedure Actions in OmniScript to fetch and combine data from multiple sources.

Salesforce Help: OmniScript Actions – Describes the Integration Procedure Action as a tool for complex data retrieval compared to DataRaptor Extract’s single-source limitation.

Explanation

The current process is functional but inefficient and violates key OmniScript best practices. Let's analyze why these two improvements are recommended.

B.Use a single DataRaptor to save the information The Problem: The OmniScript currently uses a DataRaptor to update the account after each of the three steps. This means it's making three separate DML (Data Manipulation Language) operations to create/update a single record.

The Best Practice: The best practice is to minimize the number of external calls and DML operations. A single, more complex DataRaptor (or an Integration Procedure) should be used to handle the final save of all the data at once, typically at the end of the OmniScript.

Why It's an Improvement:

Performance: Reduces system latency and processing time by making one call instead of three.

Data Integrity: Reduces the risk of partial saves or data corruption if a user abandons the OmniScript midway.

Governor Limits: Is more efficient with respect to Salesforce governor limits on DML statements.

A. Create a reusable OmniScript for this process

The Problem: The OmniScript is likely built as a "one-off" solution. If the same process for creating a billing account is needed elsewhere (e.g., in a different LWC, in a mobile app, via an API), it would have to be rebuilt.

The Best Practice: Designing OmniScripts to be reusable is a core principle. This involves using the OmniScript's Type and Sub Type properties effectively and designing it to be invoked from multiple entry points.

Why It's an Improvement:

Maintainability: If the process changes, you only need to update one reusable OmniScript, not multiple copies.

Consistency: Ensures the same business process is followed everywhere it's used.

Efficiency: Saves development time in the long run.

Why the Other Options Are Incorrect:

C. Combine the three steps into one step:
This is not a best practice from a user experience (UX) perspective. Breaking a process into logical, bite-sized steps (like the current three steps) improves usability, reduces user error, and feels less overwhelming. Combining them into one long, scrolling form would make the process more cumbersome for the agent.

D. Configure the save for later property:
The "Save for Later" feature is used when a user might need to pause a long process and resume it later (e.g., in a customer self-service portal). For an internal agent creating a billing account, this is likely an unnecessary feature. The primary problems with the script are its technical inefficiency and lack of reusability, not the inability to save progress. Enabling this property does not address the core performance and design flaws.

Summary / Key Takeaway:

The best practice improvements focus on backend efficiency (one DataRaptor call) and long-term architectural health (reusable design), not on compromising the user-facing step structure or adding unnecessary features.

Reference:

These best practices are covered in Salesforce OmniStudio documentation and Trailhead modules related to DataRaptor optimization and designing reusable OmniScripts.

Explanation

The TypeAhead element in OmniScript requires a data source that can perform a real-time search based on the user's input and return a list of matching records, along with their related fields.

The DataRaptor Extract Action is the standard and most efficient tool for this requirement because:

Search Functionality (Extract): A DataRaptor Extract is designed to query Salesforce data (like Contacts) and filter the results.

Input Parameter: The TypeAhead element automatically passes the text the user types into the input field to the DataRaptor Extract as a filter value (often called a LookupKey).

Real-Time Results: The DataRaptor uses this input to query the Contact object, typically filtering by Name using a LIKE operator, and returns the matching contacts to the OmniScript to display in the dropdown.

Retrieving Additional Data: Once the user selects a contact, the DataRaptor has already returned all mapped fields for that contact (including the Email Address), making the email instantly available in the OmniScript's Data JSON for use in a later step.

Other Supported Data Sources

While the DataRaptor Extract Action is the best fit for this specific scenario (searching Salesforce records), a TypeAhead element can also use:

HTTP Action (for external APIs)

Remote Action (for Apex code)

Integration Procedure Action (if you need complex logic before extracting data)

Data JSON (if the data is already in the OmniScript)

Explanation

The requirement involves implementing distinct verification processes for three Contact record types (Recruiter, Candidate, Trainer) with unique workflows for each (e.g., background checks for Recruiters, training classes for Trainers, certifications for Candidates). OmniStudio tools, such as FlexCards and OmniScripts, are well-suited for creating tailored, user-friendly interfaces and processes.

Let’s evaluate the options:

Specific FlexCards with Actions for each type of Contact (A):

Why it fits: FlexCards are used to display contextual data and provide actionable interfaces for users. Creating specific FlexCards for each Contact record type (Recruiter, Candidate, Trainer) allows the consultant to design tailored displays showing relevant data (e.g., contact details, verification status) for each record type. Each FlexCard can include Actions (e.g., Action elements or buttons) that trigger specific OmniScripts to handle the unique verification processes (background check for Recruiters, training for Trainers, certifications for Candidates). For example:

A Recruiter FlexCard could show contact details and a button to initiate a background check OmniScript.
A Trainer FlexCard could display training status and link to a mandatory training OmniScript.
A Candidate FlexCard could show certification progress and invoke a certification tracking OmniScript.


This approach leverages FlexCards’ ability to conditionally display data based on record type (using States or Filters) and OmniScripts’ process automation for verification workflows. It ensures a clean, record-type-specific UI and process flow, meeting the requirement effectively.

Additional benefit: FlexCards can be embedded in Lightning pages or Experience Cloud sites, providing flexibility for where the verification processes are accessed.

Multiple OmniStudio Actions that invoke separate OmniScripts (B):

Why it’s incorrect: OmniStudio Actions (e.g., Integration Procedure Action, DataRaptor Action) are used within OmniScripts to perform specific tasks like data retrieval or updates, not to directly invoke entire OmniScripts for end-user interaction. While separate OmniScripts could be created for each verification process, relying solely on Actions without a user-facing interface (like FlexCards) doesn’t provide a clear way to display contact data or initiate processes in a user-friendly manner. This option lacks the UI component needed for a complete solution.

Single FlexCard with an Action to invoke an OmniScript (C):

Why it’s incorrect: A single FlexCard could display contact data and include an Action to invoke an OmniScript, but it wouldn’t easily accommodate the distinct verification processes for each record type. A single FlexCard would require complex conditional logic (e.g., using States or Formulas) to dynamically adjust its display and actions based on the Contact record type. This approach is less maintainable and scalable compared to separate FlexCards tailored for each record type. Additionally, a single OmniScript would struggle to handle the diverse workflows (background checks, training, certifications) without becoming overly complex or requiring extensive branching logic.

Single OmniStudio Action that invokes separate OmniScripts (D):

Why it’s incorrect: Similar to option B, a single OmniStudio Action (e.g., an Integration Procedure Action) cannot directly invoke multiple OmniScripts in a user-facing context. Actions are components within an OmniScript or FlexCard, not standalone tools for orchestrating entire processes. This option also lacks a user interface for displaying contact data and initiating verification processes, making it incomplete for the requirement.

Recommended Solution

Create three FlexCards, one for each Contact record type (Recruiter, Candidate, Trainer), to display relevant contact data and verification status. Use DataRaptor Extract Actions or Integration Procedure Actions within the FlexCards to fetch record-type-specific data from Salesforce. Include Action elements on each FlexCard to invoke tailored OmniScripts for the verification processes:

Recruiter FlexCard → OmniScript for background check process.
Trainer FlexCard → OmniScript for mandatory training classes.
Candidate FlexCard → OmniScript for certification tracking.


Use Conditional Visibility or States in the FlexCards to ensure the correct card is displayed based on the Contact’s record type (e.g., using a formula or filter like RecordType.Name = 'Recruiter').
The OmniScripts can leverage Integration Procedures or DataRaptors to interact with Salesforce data (e.g., updating verification status) or external systems (e.g., background check APIs, training platforms).
This approach ensures a scalable, maintainable solution with a clear separation of concerns for each record type’s verification process, while providing an intuitive UI for users.

References

Salesforce Help: Create a Flexcard (Managed Package) – Explains how to configure FlexCards with Actions to invoke OmniScripts and display record-specific data.

Trailhead: OmniStudio FlexCards – Covers using FlexCards for contextual data display and triggering processes with Actions.

Salesforce Help: OmniScript Actions – Details how Actions in FlexCards can invoke OmniScripts for process automation.

Trailhead: Build an OmniScript – Describes designing OmniScripts for specific workflows, such as verification processes.