• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Omnistudio Consultant

Omnistudio Consultant

Checklist progress

0/149Learned

Omnistudio Consultant

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/149Learned

  • What a Flexcard is
  • How a Flexcard differs from a standard Lightning component for displaying contextual customer data
  • When to use a Flexcard versus an OmniScript to surface information to a service agent in a console
  • The role of Flexcards in a 360-degree customer view within a Service Console, including which data sources can be surfaced
  • The four supported data source types for a Flexcard (Integration Procedure, DataRaptor, Apex, REST)
  • How to choose the right Flexcard data source type for a given requirement
  • How Flexcards consume data through Integration Procedures or DataRaptors versus direct SOQL queries
  • The purpose of the Flexcard datasource refresh interval and when it should be used to meet a business requirement
  • How Flexcard states (default, conditional) work to show or hide content based on data values
  • How Flexcard element-level conditional visibility differs from state-level conditional visibility
  • When to use element-level versus state-level conditional visibility on a Flexcard
  • How Flexcard actions (flyout, modal, navigation, OmniScript launch) are configured and triggered
  • What a Flexcard flyout action does versus a modal action when launching an embedded OmniScript
  • How child Flexcards are nested inside parent Flexcards
  • The use cases that require nesting child Flexcards inside parent Flexcards
  • When each Flexcard template type is appropriate for a given data presentation requirement
  • How Flexcards are deployed to an Experience Cloud site versus a Lightning App Page
  • How a Flexcard's layout (stack, grid, list) is chosen to meet a specific presentation requirement
  • How to configure a Flexcard to iterate over a list of records and display one card per record
  • How to configure conditional states on a Flexcard to display different layouts based on a field value (e.g., case status)
  • How to use conditional visibility on individual Flexcard elements (fields, actions) versus using conditional states
  • How to use Flexcard fields to display merged data from multiple data source nodes using merge syntax
  • How to configure a Flexcard action to launch an OmniScript in a modal, passing context data to pre-populate the script
  • How to pass parameters from a parent Flexcard to a child Flexcard to filter the child's data source
  • How to place a Flexcard on a Lightning App Builder page versus an Experience Builder page
  • The configuration differences between deploying a Flexcard to Lightning App Builder versus Experience Builder
  • How to configure a Flexcard to show a custom empty state when the data source returns no records
  • How Flexcard version management and activation works
  • The impact of deactivating a Flexcard version in production
  • The process for migrating a Flexcard from one org to another using datapacks and version control considerations
  • When to use a custom LWC component embedded inside a Flexcard versus using native Flexcard elements
  • How to identify and group data from multiple Salesforce objects into a single Flexcard to create a unified customer view
  • How to structure a console layout using multiple Flexcards to display Account, Contact, and Case data side-by-side
  • How DataRaptor Extract is used as a Flexcard datasource and its limitations compared to Integration Procedures
  • How an Integration Procedure is used as a Flexcard datasource to aggregate data from multiple objects in a single callout
  • How to surface real-time external data (e.g., from an external billing system) in a Flexcard and the appropriate data source type to use
  • The tradeoff between using a single complex Integration Procedure versus multiple simpler datasources on a Flexcard
  • The hierarchical structure of an OmniScript (Script > Step > Element) and the role of each level
  • The purpose of OmniScript Type and SubType in deployment and versioning
  • The OmniScript element types available (text input, select, checkbox, date, file, signature, etc.)
  • When each OmniScript element type is appropriate for a given requirement
  • How steps and their order control navigation flow in an OmniScript and which step properties affect branching
  • The purpose and configuration of the Navigation element versus native step navigation
  • How the OmniScript JSON data model (the node structure) stores user input and is passed to integration actions
  • How OmniScript merge syntax (%variable%) works to reference data from the OmniScript JSON node anywhere in the script (labels, conditions, action inputs)
  • How conditional visibility (show/hide) is configured on steps and elements using OmniScript merge syntax
  • How the OmniScript Group and Block elements are used to organize and layout child elements within a step
  • How OmniScript actions (Integration Procedure, DataRaptor, HTTP, Apex) are added to a step
  • When each OmniScript action type fires during step execution
  • What the 'Response JSON Path' and 'Element JSON Path' fields on an OmniScript action do and why they matter
  • The role of the SetValues element and when it is used versus a DataRaptor or Integration Procedure action
  • How the OmniScript Formula element works to perform calculations or string manipulations on captured data
  • How the Repeat block and its child elements are configured to capture a variable number of records from a user
  • The OmniScript rendering modes (LWC versus Visualforce/Aura)
  • The deployment implications of OmniScript LWC versus non-LWC rendering
  • How the OmniScript Save feature (save on step navigation) works to persist in-progress data and support multi-session resumable processes
  • How the OmniScript Preview mode is used during development and its limitations
  • How an embedded OmniScript child is configured within a parent OmniScript and how data is passed between them
  • How a Calculation Procedure (Expression Set) action is invoked from within an OmniScript and how the result is mapped into the script's data JSON
  • How to review an OmniScript against a client's business process to identify missing steps or incorrect branching logic
  • The process for reviewing an OmniScript's conditional logic to confirm all branching paths align with the client's documented process flow
  • How to verify that an OmniScript captures all required data fields before allowing the user to advance to the next step
  • How to use validation rules and required field configurations in OmniScript to enforce business rules
  • How to use the OmniScript debug panel to trace data flow through steps and actions during testing
  • How error handling and error messages are configured in OmniScript actions to provide meaningful feedback to the user
  • How to verify the output of an Integration Procedure action within an OmniScript to confirm correct data is written back to Salesforce
  • The decision criteria for choosing OmniScript versus Screen Flow
  • When to use an OmniScript versus a standard Salesforce Screen Flow for a guided user process
  • Given a multi-step intake process with branching, which OmniScript step and element types should be used for each stage
  • How to map a requirement to look up and pre-populate data from an existing Salesforce record at the start of a script
  • How to configure an OmniScript to pre-populate fields using context passed from a Flexcard action
  • How to map a requirement for a branching script (e.g., different paths for new vs. existing customers) to OmniScript conditional step visibility
  • When to use a TypeAhead element versus a Select element for a field that references a large list of Salesforce records
  • How to map a requirement to collect a customer's e-signature to the appropriate OmniScript element
  • How to map a requirement for a summary review screen before final submission to the appropriate OmniScript element or step configuration
  • When the Repeatable Block element is appropriate versus creating separate steps for a varying number of items
  • How the OmniScript Aggregate element is used to combine data from multiple sources into a single node within the script JSON
  • How to choose between saving data at the end of the OmniScript versus incrementally saving at each step, and the configuration implications
  • How the OmniScript Resume feature works and when it is appropriate to enable for a multi-session business process
  • When to use a custom LWC embedded in an OmniScript versus using native OmniScript elements for a complex UI requirement

Explain the purpose and benefits of Integration Procedures and Omnistudio Data Mappers.

0/14

What a DataRaptor is and the four types (Extract, Load, Transform, Turbo Extract)

Learn this concept
Unseen

The primary use case for each DataRaptor type

Learn this concept
Unseen

The difference between DataRaptor Turbo Extract and DataRaptor Extract and when Turbo Extract is preferred

Learn this concept
Unseen

What an Integration Procedure is and how it differs from a DataRaptor

Learn this concept
Unseen

When an Integration Procedure versus a DataRaptor is the right tool for a given requirement

Learn this concept
Unseen

The key benefit of Integration Procedures running server-side in a single transaction versus multiple client-side callouts

Learn this concept
Unseen

The benefits of chaining Integration Procedure elements (e.g., DataRaptor, HTTP Action, Set Values) within a single procedure versus calling them separately

Learn this concept
Unseen

How an Integration Procedure can call external REST services and what element is used to do so

Learn this concept
Unseen

The role of DataRaptor Transform within an Integration Procedure

Learn this concept
Unseen

How DataRaptor Transform reshapes data between formats (e.g., from a REST response to Salesforce object structure)

Learn this concept
Unseen

How Integration Procedure asynchronous execution works and when it should be enabled

Learn this concept
Unseen

The impact of Integration Procedure asynchronous execution on the calling OmniScript or Flexcard

Learn this concept
Unseen

How Integration Procedure caching works (response caching on the HTTP Action element) and when caching external callout responses is appropriate

Learn this concept
Unseen

What the OmniStudio DataMapper is and how it differs from a DataRaptor in terms of configuration and capabilities

Learn this concept
Unseen

Design Integration Procedures and related Omnistudio Data Mappers.

0/14

  • How to configure input and output nodes in an Integration Procedure and how data flows between elements
  • How to pass parameters from an OmniScript to an Integration Procedure and map them into the procedure's input node
  • How to use a DataRaptor Extract element inside an Integration Procedure and map its output to a named node
  • How to design an Integration Procedure that queries multiple Salesforce objects and aggregates the results into a single output node
  • How to configure conditional logic within an Integration Procedure using the Conditional Block element to handle business rule branching
  • How to configure a Loop Block within an Integration Procedure to process a list of records and write each one to Salesforce
  • How to design a DataRaptor Load to upsert multiple Salesforce objects in a single transaction and the key configuration fields
  • How a DataRaptor Load uses a key field (external ID or Salesforce ID) to determine whether to insert or update a record, and what happens when no match is found
  • How to configure a DataRaptor Transform to reshape a JSON payload from an external API into a format compatible with a DataRaptor Load
  • How to configure error handling in an Integration Procedure to catch failures from a child element and return a meaningful error to the caller
  • How to test an Integration Procedure in isolation using the built-in test panel before connecting it to an OmniScript
  • The best practice for naming Integration Procedure elements and nodes to support maintainability and team collaboration
  • How a sub-Integration Procedure is called from a parent Integration Procedure and why this pattern is used for reusability and modularity
  • How governor limits and Salesforce platform constraints apply to DataRaptor Loads and Integration Procedures, and the best practices for staying within those limits

Describe the benefits of using Decision Matrices and Expression Sets and provide real examples.

0/11

  • What a Decision Matrix is, how it is structured (rows, columns, output values), and a real-world use case for it
  • The benefit of externalizing business rules into Decision Matrices rather than embedding them in DataRaptors or Apex
  • How a Decision Matrix is invoked from within an Integration Procedure and how its output is consumed
  • How a Decision Matrix uses input key fields and range-based matching to look up the correct output row, and how to configure the lookup keys
  • What an Expression Set is and how it differs from a Decision Matrix
  • When an Expression Set versus a Decision Matrix is appropriate for a given requirement
  • How Expression Sets use weighted scoring and conditional logic to compute a result, with an example in insurance or financial services
  • A scenario where a pricing or eligibility rule should be implemented as an Expression Set versus hard-coded logic in an OmniScript
  • How a Calculation Procedure (Expression Set) is invoked from a Flexcard or OmniScript action versus from within an Integration Procedure
  • When to invoke a Calculation Procedure from Flexcard/OmniScript versus from within an Integration Procedure
  • How to version and activate a Decision Matrix and the impact on existing Integration Procedures that reference it
  • The OmniStudio three-layer architecture (Digital Experience, Service Management, Developer Experience)
  • How a consultant uses the three-layer architecture model to categorize requirements and assign the right tool to each layer
  • How to gather requirements for a customer-facing self-service portal that uses OmniStudio components and what discovery questions to ask
  • How to translate a verbose business requirement into a minimal OmniStudio component design that avoids over-engineering
  • When a business requirement for displaying related data should be solved with a Flexcard versus an OmniScript display step
  • The best practice approach when a business requirement could be solved by either an OmniScript or a standard Lightning Flow
  • Best practices for reusing Integration Procedures and DataRaptors across multiple OmniScripts to reduce duplication
  • The best practices for naming conventions and organization of OmniStudio components to support team collaboration and maintainability
  • When to use a single complex OmniScript versus breaking a long process into child OmniScripts, and the tradeoffs involved
  • How to evaluate a proposed OmniStudio solution against Salesforce governor limits and OmniStudio platform constraints
  • How to identify which OmniStudio tool is the right entry point for a given interaction (Flexcard for display, OmniScript for process, Integration Procedure for data orchestration)
  • How a Flexcard, OmniScript, and Integration Procedure work together in an end-to-end service interaction (e.g., agent views summary, launches guided process, data is saved)
  • How Flexcard actions that launch OmniScripts pass context (record ID, field values) and how the OmniScript uses that context to pre-populate data
  • How Decision Matrices and Expression Sets plug into an Integration Procedure to implement configurable business rules at runtime
  • How to map a requirement to display aggregated data from an external system on a Flexcard to the appropriate combination of Integration Procedure and REST callout
  • How to map a multi-department business process with distinct sub-flows to a combination of parent and child OmniScripts with Integration Procedures
  • How OmniStudio components interact with standard Salesforce automation (Flows, Process Builder, Apex triggers) and the boundary considerations
  • How a DataRaptor Load inside an Integration Procedure interacts with Salesforce validation rules and what happens on failure
  • How OmniStudio components are deployed in an Experience Cloud self-service portal and the additional considerations compared to an internal Service Console deployment
  • How the IDX Build Tool and IDX Workbench are used to export, version, and migrate OmniStudio DataPacks between orgs or into a source control repository
  • How to present a fit/gap analysis to a client, distinguishing between out-of-the-box capabilities, configuration, and custom development
  • How to identify a fit where an existing DataRaptor or Integration Procedure can be reused to meet a new requirement with minimal rework
  • How to identify a business requirement that cannot be met by native OmniStudio components and requires a custom LWC or Apex extension
  • A scenario where a client requirement exceeds OmniStudio's native configuration capabilities and the consultant must recommend a custom extension strategy
  • How to prioritize which gaps to address in OmniStudio versus accepting workarounds, based on business impact and implementation cost
  • How to assess which OmniStudio components can be reused across multiple Salesforce Clouds (Service Cloud, Sales Cloud, Experience Cloud) and what adjustments are required for each target
  • How to document a gap where a legacy process built on Apex or standard Flow should be migrated to OmniStudio and the considerations involved
  • How to assess whether a client's integration requirements can be handled by OmniStudio Integration Procedures alone or require MuleSoft or middleware
  • How to evaluate a requirement for offline or mobile capabilities against what OmniStudio natively supports
  • How to evaluate a migration from the Vlocity managed package to standard Salesforce OmniStudio, including the key differences and upgrade considerations a consultant must communicate to the client

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Omnistudio Consultant studiers. 593 members and growing.

Go to Discord

The benefits of chaining Integration Procedure elements (e.g., DataRaptor, HTTP Action, Set Values) within a single procedure versus calling them separately

Explainer

Learn More

Practice Question

Keep going

Next conceptHow an Integration Procedure can call external REST services and what element is used to do so

Checklist progress

0/149 (0%)

0 of 149 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Omnistudio Consultant studiers. 593 members and growing.

Go to Discord

Explainer

Omnistudio Integration Procedures are server-side declarative processes that automate data interactions between Salesforce and external systems. They bundle multiple actions, such as Data Mappers and API calls, into a single server call to reduce round trips and offload processing. This approach centralizes complex logic and separates front-end interface design from back-end data management.

Core information
  • Integration Procedures execute multiple actions in a single server call, preventing round trips to the server that occur when calling elements separately.
More details and nuances
  • By default, all actions in an Integration Procedure run in a single transaction, and exceeding a Salesforce governor limit ends the transaction and fails the procedure.