Omnistudio Fundamentals18% of the exam
Requirements, risks and constraints for Omnistudio projects
How a developer turns Omnistudio requirements into a build plan: standard components first and minimal custom code, which requirements point to the standard runtime, which planning assumptions are really migration risks (Angular, Data Mapper versions, names, industry objects, test locators), and the sandbox-first constraint.
Determine a project's needs by evaluating a customer's requirements, assumptions, risks, and constraints.
~7 min read · 9 practice questions ·
What the exam expects
- Choose declarative configuration first and limit custom code to a small, generic extension when a standard element falls short.
- Identify which customer requirements point to the standard runtime and which point at rework in either runtime.
- Classify plan assumptions as risks: Angular components, multiple Data Mapper versions, names with special characters, reserved keywords, industry objects, parallel development and test locators.
- Map a non-functional requirement such as latency to the build-time tool that checks it.
- Apply the sandbox-first constraint and baseline testing before migration.
Key terms:
- Assumption: something the plan treats as true without proof; when an official page contradicts it, it is a risk.
- Hybrid design: standard Omnistudio components plus minimal custom components.
- Assess mode: the Migration Assistant run that reports readiness without modifying data.
- Design Assistant: real-time component health feedback inside the designers.
Key facts
Build order
- Detail
- Standard components first; customize only when necessary; hybrid design for new components
Angular
- Detail
- Angular Omniscripts and Flexcards unsupported in both runtimes
Data Mapper versions
- Detail
- Multiple versions of a Data Mapper block migration
Names
- Detail
- Underscores not allowed in standard runtime component names
Reserved keywords
- Detail
- "response", "request" and "action" must be renamed in Integration Procedures
Test automation
- Detail
- HTML element tags differ between runtimes
Design-time quality
- Detail
- Design Assistant: real-time health and performance feedback
First step
- Detail
- Refresh a sandbox from production and record a test baseline
Sources for this section (6)
- Best Practices, Technologies, and Developer Toolstrailhead.salesforce.com (opens in a new tab)
- Supported Featureshelp.salesforce.com (opens in a new tab)
- Migrate to Standard Runtimehelp.salesforce.com (opens in a new tab)
- Migration Assistant blogdeveloper.salesforce.com (opens in a new tab)
- New Omnistudio Featurestrailhead.salesforce.com (opens in a new tab)
- Migration blogdeveloper.salesforce.com (opens in a new tab)
- Why is a hybrid design preferred over an all-custom LWC build?
- Why would an Integration Procedure with an element named "action" appear in an Assess report?
- When is Assess mode the wrong tool for a performance concern?
- Why leave the managed package installed during a migration?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Omnistudio Developer pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 46 lessons of the Omnistudio Developer guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (9 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams