--- name: omnistudio-vs-standard-decision description: "Decision framework for choosing OmniStudio (OmniScript, FlexCards, Integration Procedures) vs standard Salesforce tooling (Screen Flow, LWC, Apex) for guided UI and data transformation use cases: capability matrix, license availability gate, team skills assessment, and migration path from managed package to Standard Designers. NOT for OmniStudio implementation or configuration." category: architect salesforce-version: "Spring '25+" well-architected-pillars: - Operational Excellence - Operational Excellence triggers: - "should I use OmniStudio or Screen Flow for this guided process" - "we have FSC licensed — when should we use OmniScript vs standard Flow" - "OmniStudio vs LWC vs Flow — which is right for our team" - "migrating from OmniStudio managed package to Standard Designers on-platform" - "evaluating OmniStudio for a Sales Cloud org without Industries license" tags: - omnistudio - omni-studio - screen-flow - lwc - decision-framework - industries - architecture inputs: - "Salesforce edition and licenses held by the org (e.g., FSC, Health Cloud, Sales Cloud)" - "Desired UI capability: guided multi-step, data lookup, or single-object form" - "Team skills profile: OmniStudio expertise available or not" - "Existing deployment state: managed package OmniStudio vs Standard Designers (on-platform)" outputs: - "OmniStudio vs Standard tooling recommendation with rationale" - "Capability matrix comparing OmniStudio and standard equivalents" - "Migration path assessment for managed-package-to-Standard-Designers upgrade" dependencies: - platform-selection-guidance version: 1.0.0 author: Pranav Nagrecha updated: 2026-04-13 --- # OmniStudio vs Standard Decision This skill activates when a practitioner needs to decide between OmniStudio (OmniScript, FlexCards, Integration Procedures) and standard Salesforce tooling (Screen Flow, LWC, Apex) for a guided UI or data transformation use case. It evaluates license availability, capability fit, team readiness, and migration path. --- ## Before Starting Gather this context before working on anything in this domain: - **License confirmation:** Verify whether the org holds an Industries Cloud license (FSC, Health Cloud, Manufacturing Cloud, Nonprofit Cloud, Education Cloud). OmniStudio is NOT included in Sales Cloud or Service Cloud without an add-on. License availability is the primary decision gate — if the org is not licensed, the decision is already made. - **Existing deployment state:** Determine whether the org is using the managed-package OmniStudio (`vlocity_ins__` or `industries__` namespace) or has migrated to Standard Designers (native LWC, no managed package). These are not interchangeable without an explicit migration. - **Team skills:** Assess whether the team has OmniStudio expertise. OmniStudio has its own runtime, designer tools, and data model that require specific training. Assuming developers can adopt it without ramp time is the most common wrong assumption. - **Use case complexity:** Identify the number of objects, data sources, and external callouts involved. The complexity threshold is the key driver for OmniStudio vs standard tooling. --- ## Core Concepts ### License Gate OmniStudio is included in Industries Cloud licenses: Financial Services Cloud (FSC), Health Cloud, Manufacturing Cloud, Nonprofit Cloud, and Education Cloud. It is NOT included in core Sales Cloud or Service Cloud without a separate Industries add-on license. Attempting to use OmniStudio components in an unlicensed org will fail at runtime. This is not a configuration issue — it is a licensing restriction enforced by Salesforce. Confirm license availability before designing any solution that depends on OmniStudio. Source: https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_overview.htm ### Managed Package vs Standard Designers Before Spring '25, OmniStudio was delivered as a managed package using either the `vlocity_ins__` namespace (legacy Vlocity) or the `industries__` namespace (post-acquisition Salesforce packaging). Standard Designers, introduced and matured through Spring '25 and Spring '26, run natively on-platform using the standard LWC runtime with no managed package. These two deployment models are architecturally distinct: - Managed-package orgs use namespace-prefixed fields, Apex classes, and metadata types specific to the package. - Standard Designers orgs use standard platform metadata types with no prefix. - Migration from managed package to Standard Designers is an explicit, non-trivial project — it is not automatic and cannot be done incrementally component by component in all cases. Source: https://developer.salesforce.com/blogs/2024/omnistudio-standard-designers ### OmniStudio Capability Envelope OmniStudio excels in three areas where standard tooling is comparatively weak: 1. **Multi-step guided UIs across multiple related objects** — OmniScript provides a step-based interaction model that is declarative and reusable across channels (LWC, Communities, Mobile). Screen Flow provides similar capabilities for simpler single-object scenarios but becomes complex to maintain as object breadth and branching logic grow. 2. **Multi-source data transformations** — Integration Procedures orchestrate data from multiple Salesforce objects and external REST APIs in a single declarative configuration, with built-in caching, parallel branching, and conditional logic. The Apex equivalent requires custom service classes, governor limit management, and significantly more code. 3. **Declarative HTTP callouts without Apex** — Integration Procedures support HTTP Action elements that call external REST endpoints declaratively, without writing Apex. This reduces the need for Apex developers on teams that primarily work declaratively. ### Standard Tooling Capability Envelope Screen Flow + LWC + Apex is the correct choice when: - The use case is single-object or simple (one or two related objects) - The org does not have an Industries license - The team does not have OmniStudio expertise and the build timeline does not allow for ramp - Long-term maintainability by a general Salesforce admin or developer team is a priority - The complexity of the scenario does not justify the licensing cost or migration overhead --- ## Common Patterns ### Pattern 1: OmniScript + Integration Procedure for Multi-Source Guided UI **When to use:** The org is Industries-licensed, the UI spans multiple Salesforce objects and/or external data sources, and the team has OmniStudio training. **How it works:** 1. Design an Integration Procedure to retrieve data from Account, Contact, and any external REST endpoint in a single call. 2. Build an OmniScript that uses the Integration Procedure as a data source for each step. 3. Expose FlexCards on the record page to surface summary data and launch the OmniScript. 4. Embed the OmniScript in a Community or Lightning App page as needed. **Why not the alternative:** A Screen Flow equivalent would require multiple Get Records elements, custom LWC components for complex display, and custom Apex for external callouts. The build and maintenance cost is significantly higher at this complexity level. ### Pattern 2: Screen Flow + LWC for Single-Object Guided Process **When to use:** The org does not hold an Industries license, or the use case involves one or two objects with no external callouts. **How it works:** 1. Design a Screen Flow with screen steps for each stage of the guided process. 2. Use standard Get/Update Records elements for data operations. 3. Embed custom LWC components for any complex display logic. 4. Invoke Apex only if governor limits or callout requirements demand it. **Why not the alternative:** OmniStudio would require an Industries license the org does not have, and adds architectural complexity (designer tools, namespace, runtime) for a use case that Screen Flow handles adequately. --- ## Decision Guidance | Situation | Recommended Approach | Reason | |---|---|---| | Org is licensed for FSC, Health Cloud, Manufacturing, Nonprofit, or Education Cloud | OmniStudio is available — evaluate capability fit | License gate is satisfied | | Org is on Sales Cloud or Service Cloud without Industries add-on | Standard tooling only (Screen Flow, LWC, Apex) | OmniStudio not licensed | | Multi-step UI spanning 3+ objects and/or external REST callouts, licensed org | OmniStudio (OmniScript + Integration Procedure) | Declarative multi-source orchestration, lower dev cost at scale | | Single-object or two-object guided process | Screen Flow + LWC | Adequate capability, lower complexity, no license dependency | | Team has no OmniStudio training and timeline is tight | Standard tooling | OmniStudio ramp time will exceed build time for simple scenarios | | Org uses managed-package OmniStudio and considering migration | Assess migration scope before committing | Migration is non-trivial; managed-package and Standard Designers are architecturally distinct | | New org starting from scratch, Industries-licensed | Standard Designers (on-platform) — no managed package | Managed package is a legacy path; Standard Designers is the Salesforce-recommended forward path | --- ## Recommended Workflow Step-by-step instructions for an AI agent or practitioner working on this task: 1. **Confirm license:** Retrieve the org's installed licenses (Setup > Company Information > Licenses) and verify whether an Industries Cloud license is present. If not, standard tooling is the only option — stop here and recommend Screen Flow + LWC + Apex. 2. **Assess use case complexity:** Identify the number of Salesforce objects involved, whether external REST callouts are required, and whether the UI must span multiple steps with branching logic. Use the decision table above to map complexity to tooling. 3. **Evaluate team skills:** Confirm whether the project team includes certified OmniStudio developers or admins. If not, factor in training time and whether the timeline permits it. 4. **Check deployment state:** If the org already uses OmniStudio, determine whether it is the managed package or Standard Designers. If managed package, assess migration readiness before adding new OmniStudio components — mixing approaches creates technical debt. 5. **Produce recommendation:** Document the decision with rationale covering license status, use case fit, team readiness, and deployment state. Use the capability matrix and decision table as supporting evidence. 6. **Validate against official sources:** Confirm any capability or limit claims against current Salesforce documentation. OmniStudio has evolved rapidly — assume information older than two releases may be stale. --- ## Review Checklist Run through these before marking work in this area complete: - [ ] License availability confirmed for the specific org (not assumed from cloud edition name alone) - [ ] Use case complexity mapped to the decision table (number of objects, external callouts, step count) - [ ] Team skills assessed and ramp time factored into the recommendation - [ ] Deployment state confirmed: managed package vs Standard Designers - [ ] Migration path documented if org is on managed package and OmniStudio is recommended - [ ] Recommendation includes explicit rationale, not just a tool name - [ ] All factual claims verified against current official Salesforce documentation --- ## Salesforce-Specific Gotchas Non-obvious platform behaviors that cause real production problems: 1. **OmniStudio license is per-org, not per-user** — The Industries license enables OmniStudio for the entire org. However, if the license lapses or is not renewed, all OmniStudio components fail at runtime for all users. There is no graceful degradation. Build a dependency audit into license renewal planning. 2. **Managed package and Standard Designers cannot coexist arbitrarily** — Some component types from the managed package conflict with their Standard Designers equivalents. Migration requires a structured plan using Salesforce's OmniStudio Conversion Tool and cannot be done component by component in all configurations. 3. **FlexCards are not available in Lightning App Builder without OmniStudio license** — FlexCard components appear as broken or invisible on pages when viewed in an unlicensed org or sandbox that has lost its license. This causes silent failures in page layouts that are difficult to diagnose. 4. **Integration Procedure callout limits differ from Apex** — Integration Procedures share the org's HTTP callout governor limits with Apex but are subject to their own per-transaction timeout constraints. Long-running Integration Procedures can time out in ways that Apex with explicit async patterns would not. --- ## Output Artifacts | Artifact | Description | |---|---| | Decision recommendation | Written rationale covering license status, use case fit, team readiness, and deployment state | | Capability matrix | Side-by-side comparison of OmniStudio and standard tooling for the specific use case | | Migration path assessment | If the org is on managed-package OmniStudio, a scoped assessment of what migration to Standard Designers would require | --- ## Related Skills - platform-selection-guidance — broader platform tooling decision framework; Decision Area 4 covers OmniStudio at a high level; use this skill to go deeper - omnistudio-testing-patterns — once OmniStudio is selected, use for testing OmniScript and Integration Procedure implementations - omnistudio-ci-cd-patterns — once OmniStudio is selected, use for deployment pipeline design --- ## Official Sources Used - OmniStudio Overview — https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_overview.htm - OmniStudio Standard Designers Blog — https://developer.salesforce.com/blogs/2024/omnistudio-standard-designers - Salesforce Well-Architected Overview — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html