Conceptual, logical and physical models for Omnistudio
How to move an Omnistudio solution from business concepts to a logical entity model and then to physical objects: virtual entities for external data, logical versus physical optionality, consolidating entities with record types, master-detail versus lookup, standard versus custom objects, account data skew, and the objects that store Omnistudio components.
Guide in the creation of a Conceptual Model, Logical Model, and Physical Model to support the business solution, including recommending optimal object design (standard vs. custom) to support Omnistudio artifacts.
~7 min read · 7 practice questions ·
What the exam expects
- Explain what conceptual, logical and physical models each show, and walk an Omnistudio solution from one to the next.
- Model data that stays outside Salesforce as a virtual entity reached through an Integration Procedure or Salesforce Connect.
- Read a Salesforce ERD: logical versus physical optionality, master-detail versus lookup, record-type subtypes.
- Recommend consolidating similar entities into one object with record types, and decide standard versus custom objects from out-of-the-box features and licenses.
- Keep child records per account below the data skew threshold.
- Name the standard objects that store Omnistudio components on the Standard Runtime.
Key terms: logical model (business entities and relationships, no physical detail); physical model (objects, fields and relationship types in the org); virtual entity (in the logical model, not stored as an object); record type (subtype of one object); master-detail (required parent with cascade delete and inherited visibility); data skew (more than 10,000 child records on one parent).
Key facts
- Detail
- Business entities and relationships, no physical considerations
- Detail
- No border in an ERD; data via external APIs or Salesforce Connect
- Detail
- Dashed border in an ERD
- Detail
- Cascade delete; detail visibility follows the parent
- Detail
- Physically optional, logically required (ignoring private contacts)
- Detail
- More than 10,000 child records on one parent
- Detail
- Custom apps and core objects; no opportunities, leads, campaigns or forecasts
- Detail
- Omni Process, Omni Data Transformation, Omni UI Card
Sources for this section (5)
- Enterprise Data Architecturedeveloper.salesforce.com (opens in a new tab)
- Data Model Notationarchitect.salesforce.com (opens in a new tab)
- Design Your Data Modeltrailhead.salesforce.com (opens in a new tab)
- Standard User Licenseshelp.salesforce.com (opens in a new tab)
- Omnistudio Naming Conventionshelp.salesforce.com (opens in a new tab)
- Why might an architect consolidate three similar logical entities into one object?
- When should an entity be drawn as a virtual entity?
- Which two considerations decide between a standard and a custom object?
- Which Standard Runtime object stores both Omniscripts and Integration Procedures?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Omnistudio Consultant pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 31 lessons of the Omnistudio Consultant guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (7 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams