Salesforce Industries (Vlocity): Architecture Behind Vertical Clouds

From Vlocity to Salesforce Industries

Vlocity was an ISV that built vertical-specific accelerators on the Salesforce platform for telecoms, insurance, health, public sector, and media. Each vertical product contained pre-built data models, business processes (via OmniStudio), pricing engines, and integration templates. When Salesforce acquired Vlocity in 2020 for $1.33 billion, it rebranded the portfolio as Salesforce Industries and integrated OmniStudio into the platform proper.

Today, Salesforce Industries encompasses more than 12 vertical clouds: Communications Cloud, Media Cloud, Energy & Utilities Cloud, Financial Services Cloud, Health Cloud, Public Sector Solutions, Net Zero Cloud, Education Cloud, Nonprofit Cloud, Consumer Goods Cloud, Manufacturing Cloud, and Automotive Cloud. Each is a managed package installed on top of the core Salesforce platform.

The Three-Layer Architecture

Every Salesforce Industries cloud has the same three-layer structure:

1. Foundation layer: The core Salesforce platform — objects, Apex, LWC, Flows, Security. Industries inherits all platform capabilities and limits.
2. Industries layer: The managed package — vertical-specific data model extensions, OmniStudio assets (OmniScripts, FlexCards, Integration Procedures), EPC (Enterprise Product Catalogue), Decision Matrix, and pre-built Apex service classes.
3. Customisation layer: Customer-specific configuration and code that extends or modifies the Industries layer. This is where the implementation team works.

The critical constraint is that customisation must flow downward — customer code can extend the Industries layer but cannot modify the managed package internals. This is the same constraint as any managed package implementation, but the Industries packages are significantly larger and more complex than typical ISV packages.

Enterprise Product Catalogue (EPC)

EPC is the product modelling engine at the heart of Communications, Media, and Energy Industries clouds. It is the component that makes these clouds genuinely different from standard CPQ.

Where standard Salesforce CPQ models products as records in a flat Product object, EPC models products as hierarchical bundles with complex offer eligibility, configurability, and compatibility rules. A telecom offering might be: a Bundle (Home Internet + TV + Mobile), containing Service Components (Broadband, IPTV, SIM), each with Characteristics (Speed, Channels, Data Allowance), Pricing Rules (base price, discount tiers, promotional periods), and Compatibility Constraints (broadband speed determines available TV packages).

// EPC hierarchy (simplified)
Catalog
  Product Offering (e.g. "Quad Play Bundle")
    Product Spec (e.g. "100Mbps Broadband")
      Characteristic Spec (e.g. "Download Speed")
      Characteristic Spec (e.g. "Upload Speed")
    Product Spec (e.g. "Premium TV")
      Characteristic Spec (e.g. "Channel Count")
    Offer Price (monthly recurring charge)
    Offer Price (activation fee)
    Offer Eligibility Rule (geographic availability)
    Offer Compatibility Rule (bundles TV only with broadband)

Customisation Constraints and Upgrade Risk

Industries managed packages receive updates on the Salesforce release cycle (3 per year). Unlike the core platform where upgrades are automatic and controlled by Salesforce, managed package upgrades are controlled by the customer — but they must eventually be applied or the package falls out of support.

The customisation risk surface for Industries implementations:

• OmniStudio assets: Customised OmniScripts and DataRaptors may conflict with updated versions shipped in the package upgrade. Industry OmniStudio assets need version-tracking.
• Apex overrides: The Industries package exposes virtual and global Apex classes for extension. If the signature of a global method changes in an upgrade, custom subclasses break.
• Data model extensions: Fields added to Industries objects are customer-owned. Object renames or structural changes in package upgrades can break integrations built on the old field names.
• EPC product data: EPC data (product specs, characteristics, pricing) is configuration data, not metadata. It does not migrate via Metadata API — custom ETL tooling or DataRaptor loads are needed between sandboxes and production.

When Industries Clouds Are the Right Choice

An Industries cloud is the right starting point when three conditions align:

1. Vertical fit: The customer's core business domain maps directly to an Industries vertical (telecom, insurance, health, utilities). If the fit is marginal, the pre-built data model creates more friction than value.
2. Process fit: The customer's target processes (order management, claims processing, network provisioning, care management) are close to the Industries accelerator processes. Heavy customisation of OmniStudio assets erodes the speed advantage.
3. OmniStudio commitment: The implementation team and the customer's ongoing admin team are willing to invest in OmniStudio expertise. Industries clouds are deeply OmniStudio-dependent — organisations that resist OmniStudio adoption will fight the product constantly.

Governance for Long-Term Industries Implementations

Industries implementations that survive years of operation share these governance practices:

• Upgrade sandbox cadence: Maintain a permanent upgrade sandbox where each Salesforce release is applied before production. Test all customised OmniStudio assets and Apex extensions against the new package version.
• Customisation inventory: Document every override of a managed package component — Apex class extension, OmniStudio asset clone, EPC model extension. This inventory drives upgrade testing scope.
• EPC data pipeline: Build and maintain an automated pipeline for promoting EPC product catalogue data between environments. Manual migration does not scale past 50 product specs.
• OmniStudio version control: Use LWC-native mode (available since Summer 2023) to store OmniStudio assets as source-controlled metadata rather than data records.