Industries Cloud Selection

Industries Cloud Selection

This skill activates when a practitioner or architect must determine which Salesforce Industries vertical cloud fits a customer's industry, data model requirements, and licensing constraints. It produces a structured vertical cloud recommendation grounded in data model compatibility, standard object availability, and license gating. It does not cover implementation, configuration, OmniStudio component development, or data migration after the cloud has been selected.

Before Starting

Gather this context before working on anything in this domain:

• Identify the required standard objects first. Salesforce Industries clouds are license-gated, and the key selection driver is which vertical cloud's license provides the standard objects the solution actually needs. Ask: "What standard objects — InsurancePolicy, ServicePoint, BillingAccount, EnterpriseProduct — does this solution require?" before evaluating any other factor.
• Most common wrong assumption: Practitioners frequently assume that standard objects like InsurancePolicy, ServicePoint, or BillingAccount are available in a base Salesforce org or that they can be created as custom objects as a substitute. They cannot. These objects only exist in orgs licensed for the corresponding vertical cloud. No license means no object, no data, no solution.
• OmniStudio packaging is now a one-way door. As of Spring '26, new orgs provisioned with a Salesforce Industries license receive OmniStudio platform-native (included in the core Salesforce platform). Opening a managed-package OmniStudio component in the Standard Designer to convert it to platform-native is a one-way migration — the component can no longer be edited in the managed-package designer afterward.
• License modules are additive, not interchangeable. Several vertical clouds are built on a base cloud and require both licenses. For example, Insurance Cloud requires Financial Services Cloud (FSC) as its base layer. Purchasing Insurance Cloud modules without FSC is not a valid configuration.

Core Concepts

Salesforce Industries Is a License-Gated Portfolio — Not a Configuration Option

Salesforce Industries is a portfolio of vertical-specific cloud products, each delivered as a separately licensed addition to the Salesforce Platform. Each vertical cloud adds a distinct set of standard Salesforce objects, industry-specific data models, pre-built OmniStudio components, and business rules that are not available in a standard Salesforce org.

This means vertical cloud selection is primarily a data model compatibility decision:

• If a solution requires InsurancePolicy, the org must be licensed for Insurance Cloud.
• If a solution requires ServicePoint or UtilityAccount, the org must be licensed for Energy & Utilities Cloud.
• If a solution requires BillingAccount or ProductCatalog with TM Forum–aligned order decomposition, the org must be licensed for Communications Cloud.

No configuration workaround, custom object substitution, or AppExchange alternative replaces the license-gated standard objects. These objects carry pre-built relationships, validation rules, platform behavior, and integration hooks designed for the vertical — reimplementing them in custom objects loses all of that.

Vertical Cloud Standard Object Landscape

Each vertical cloud introduces a characteristic set of standard objects that anchor the data model:

OmniStudio Packaging: Platform-Native vs Managed Package

OmniStudio is the low-code tooling layer shared across all Salesforce Industries clouds. As of Spring '26, new Industries-licensed orgs receive OmniStudio as a platform-native feature included in the Salesforce Platform (no separate managed package required). Existing orgs provisioned before this change may still run the OmniStudio managed package.

This packaging decision has permanent architectural consequences:

• Platform-native OmniStudio stores components as Salesforce metadata (deployable via Metadata API, versioned in source control, available in scratch orgs).
• Managed-package OmniStudio stores components in managed package namespaces not visible to standard metadata retrieval.
• The migration from managed package to platform-native is one-way. Once a component is opened in the Standard Designer and converted, it cannot be returned to the managed-package designer.
• Selection must confirm which model the org uses before recommending component design patterns.

Customization vs Configuration in Vertical Clouds

Each vertical cloud offers a spectrum of extension options:

• Configuration: Using the industry-standard objects, page layouts, record types, and pre-built OmniStudio flows without modification. This is the fastest path to value and carries the lowest upgrade risk.
• OmniStudio customization: Building or extending OmniScripts, FlexCards, DataRaptors, and Integration Procedures to adapt standard components to customer-specific processes. These components are versioned and can be upgraded independently.
• Apex and Flow customization: Extending the vertical cloud's data model with custom fields, custom objects, Apex triggers, and Flow automation layered on top of industry standard objects.
• Anti-pattern: Replacing industry standard objects with custom objects when the standard object's behavior is undesirable — this destroys upgrade compatibility and eliminates the data model advantages that justified the license purchase.

Common Patterns

Pattern 1: Object-First Vertical Selection

When to use: A new customer or internal team is evaluating which Salesforce Industries license to purchase, and the primary driver is functional requirements, not industry affiliation.

How it works:

1. List every business entity the solution must model (e.g., "policy," "covered vehicle," "premium payment").
2. Map each entity to the nearest Salesforce standard object across vertical clouds using the object landscape table above.
3. Identify which vertical cloud license provides the maximum coverage of required standard objects.
4. Flag any entities not covered by any vertical and plan for custom object extensions layered on top.
5. Confirm license dependencies (e.g., if Insurance objects are required, FSC base is also required).

Why not the alternative: Selecting a vertical cloud based on industry name alone (e.g., "we are a financial services firm so we need FSC") without checking which specific standard objects are required can result in a mismatch — a fintech firm processing insurance policies needs Insurance Cloud (which builds on FSC), not FSC alone.

Pattern 2: Greenfield vs Retrofit Assessment

When to use: An existing Salesforce customer is considering adding an Industries license to their current org.

How it works:

1. Audit existing custom objects that duplicate standard vertical cloud objects (e.g., a custom Policy__c object when InsurancePolicy is about to become available).
2. Assess migration cost: migrating from custom objects to industry standard objects requires data migration, field remapping, and process rebuild.
3. Compare retrofit cost against greenfield org cost.
4. Confirm the existing org's OmniStudio packaging model (managed package or platform-native) before planning any OmniStudio component work.
5. Evaluate whether a new sandbox provisioned with the Industries license can serve as a proof-of-concept before full commitment.

Why not the alternative: Adding an Industries license to a mature org without auditing the existing data model leads to object conflicts, naming collisions, and expensive migration work that was not scoped in the project estimate.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner guiding vertical cloud selection:

1. Identify the required standard objects. Before evaluating any vertical cloud by name, list every business entity the solution must model. Map each to the nearest industry standard object using the vertical cloud object landscape. This is the primary selection signal — not the customer's industry name.
2. Determine license dependencies. Check whether any required vertical cloud has a base license dependency (e.g., Insurance Cloud requires FSC). Confirm all required licenses are in scope for the purchase.
3. Assess the OmniStudio deployment model. Confirm whether the org will be new (platform-native OmniStudio, Spring '26+) or existing (potentially managed package). If existing, identify which OmniStudio model is in use before planning any component work. Flag the one-way migration risk if managed-package components are involved.
4. Evaluate customization vs configuration tradeoffs. For each business process, determine whether pre-built vertical cloud components (OmniStudio flows, page layouts, guided setup) cover the requirement or whether custom development is needed. Document the delta explicitly.
5. Document the data model compatibility assessment. Produce a table mapping each required business entity to the standard object it will use, the vertical cloud license required, and any gaps requiring custom extension.
6. Identify open questions that could change the recommendation. List any unclear requirements — edition tier (Growth vs Enterprise), Hyperforce vs legacy, existing custom object conflicts — that must be resolved before finalizing the recommendation.
7. Produce the formal recommendation. Write a documented vertical cloud recommendation citing each driving factor: required standard objects, license dependencies, OmniStudio model, and known customization requirements. Include a risk log for any assumptions made.

Review Checklist

Run through these before marking work in this area complete:

• Required standard objects are identified and mapped to the vertical cloud that provides them
• License dependencies are confirmed (e.g., Insurance Cloud requires FSC base)
• OmniStudio deployment model (platform-native vs managed package) is documented
• One-way Standard Designer migration risk is flagged if managed-package components are involved
• Customization vs configuration tradeoffs are assessed for key business processes
• Existing org custom object conflicts are identified for retrofit scenarios
• Open questions that could change the recommendation are logged
• Edition tier (Growth vs Enterprise) is confirmed or flagged as outstanding

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Industry standard objects are license-gated — no license, no object. Standard objects like InsurancePolicy, ServicePoint, and BillingAccount do not appear in a Salesforce org unless the corresponding vertical cloud license is active. They cannot be created as custom objects and used as substitutes without losing all platform behaviors (relationships, validation, API behaviors) those objects carry. Attempting to use SOQL against InsurancePolicy in an unlicensed org returns an error, not an empty result.
2. Insurance Cloud requires FSC as a base — they are not alternatives. A common mistake is treating Financial Services Cloud and Insurance Cloud as competing options for a financial services firm. Insurance Cloud modules are built on top of FSC. An org licensed for Insurance Cloud must also hold an FSC license. Proposing Insurance Cloud without FSC in the license scope results in an invalid configuration that cannot be provisioned.
3. OmniStudio Standard Designer migration is permanent and irreversible. Once a managed-package OmniStudio component (OmniScript, FlexCard, DataRaptor) is opened in the Standard Designer as part of a platform-native migration, it can no longer be edited in the managed-package designer. This applies even if the migration is aborted midway. Any existing managed-package OmniStudio customizations must be fully scoped before beginning migration, and rollback is not available.

Output Artifacts

Related Skills

• architect/industries-data-model — Use after selecting a vertical cloud to understand the detailed data model, object relationships, and extension patterns for the chosen cloud
• admin/industries-process-design — Use after selection to design OmniStudio-based process flows for the chosen vertical cloud
• data/industries-data-migration — Use when migrating existing data from custom objects or legacy systems to industry standard objects
• data/omnistudio-metadata-management — Use when managing OmniStudio component lifecycle, versioning, and deployment across environments
• architect/platform-selection-guidance — Use upstream when the question is broader than vertical cloud selection (e.g., whether to use Salesforce Industries at all vs standard platform)