SfSkills Domains Docs GitHub

Home / architect / health-cloud-multi-cloud-strategy

health-cloud-multi-cloud-strategy

Use this skill when designing the license model, cloud topology, and org structure for a Salesforce Health Cloud implementation that involves more than one Salesforce cloud product (Experience Cloud patient portals, OmniStudio engagement flows, Marketing Cloud care campaigns, or Service Cloud case management).

Open the skill folder on GitHub

Health Cloud Multi-Cloud Strategy

This skill activates when an architect or practitioner needs to design the cross-cloud license model and org topology for a Salesforce Health Cloud implementation that spans multiple Salesforce products. It provides decision guidance on which clouds are bundled, which are separate add-ons, how permission sets must be assigned per persona, and what compliance obligations attach to each cloud connection.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

Health Cloud Builds on Top of CRM — Service Cloud Is Included

Health Cloud is not a standalone product. It is a managed package and permission set layer delivered on top of a standard Salesforce CRM org (Sales Cloud + Service Cloud at the same edition level). Every Health Cloud license implicitly includes Service Cloud capabilities — case management, entitlements, omni-channel routing, and the full Case object — at no additional license cost for internal users. Care coordinators use Service Cloud Cases as the backbone of care coordination without needing a separate Service Cloud license.

Consequence: Do not add Service Cloud as a separate line item in architecture or licensing documentation for internal care team users. It creates confusion and may lead procurement to purchase redundant licenses.

Experience Cloud for Health Cloud Is a Separate Paid Add-On

Patient-facing portals and caregiver portals built on Experience Cloud are NOT included in a standard Health Cloud license. They require the Experience Cloud for Health Cloud add-on SKU, which provisions:

Each external portal user must be assigned the Health Cloud for Experience Cloud permission set license. Failure to do this is the single most common licensing error in Health Cloud implementations.

OmniStudio Bundled But Requires Explicit PSL Assignment

OmniStudio (FlexCards, OmniScripts, Integration Procedures, DataRaptors) is packaged within Health Cloud licenses — customers do not purchase OmniStudio separately when they have Health Cloud. However, activation requires three explicit permission set assignments for each internal user who needs OmniStudio:

  1. Health Cloud permission set license
  2. Health Cloud Platform permission set license (provides object-level access to Health Cloud data model objects)
  3. OmniStudio User permission set license

If any of the three is missing, OmniStudio components will be visible in the metadata but will fail silently or throw permission errors at runtime for that user.

Marketing Cloud Health Cloud Connect and the HIPAA BAA Gap

Marketing Cloud can be connected to Health Cloud to enable care program campaign management, appointment reminders, and patient re-engagement journeys via Marketing Cloud Health Cloud Connect (the managed integration package). However:

Common Patterns

Three-Tier Patient Portal Architecture

When to use: The implementation includes patient self-service (appointment scheduling, care plan viewing, secure messaging) alongside internal care coordinator workflows.

How it works:

Why not the alternative: Building the patient portal as a separate Salesforce org (a "portal org") introduces bidirectional sync complexity, duplicate identity management, and doubles the compliance surface. Single-org with Experience Cloud for Health Cloud is strongly preferred unless strict data residency requirements make a separate org necessary.

Care Coordination Hub with OmniStudio Guided Flows

When to use: The care team requires standardized, multi-step intake assessments (SDOH screening, medication reconciliation) that must be auditable and configurable without code deployments.

How it works:

All of this runs within the standard Health Cloud org under the bundled OmniStudio entitlement — no separate OmniStudio license purchase required, but each user needs all three PSLs assigned (see Core Concepts).

Why not the alternative: Custom LWC-based wizards require code deployments for every assessment change, cannot be managed by non-developer care program staff, and lack the built-in audit trail that OmniScripts provide through the OmniProcess execution log.

Single-Org vs. Hub-and-Spoke for Multi-Entity Health Systems

When to use: The health system has multiple hospitals, clinics, or business units that may need data isolation while sharing a Salesforce contract.

How it works:

Why not the alternative: Hub-and-spoke dramatically increases license cost, deployment complexity, and integration maintenance. Architects should exhaust single-org isolation patterns before recommending multiple orgs.

Decision Guidance

Use CaseCloud / License RequiredIncluded in Health Cloud?Notes
Internal care coordinator case managementService Cloud (Cases, Omni-Channel)Yes — implicitNo separate purchase needed
Patient self-service portalExperience Cloud for Health Cloud (add-on SKU)No — separate add-onPer-external-user PSL required
Guided care assessment flows (OmniScripts)OmniStudioYes — bundledRequires 3 PSL assignments per user
Appointment reminder and re-engagement campaignsMarketing Cloud + Health Cloud ConnectNo — separate productRequires dedicated Marketing Cloud HIPAA BAA before PHI is sent
EHR integration (Epic, Cerner)MuleSoft or named credential calloutsNot includedMuleSoft licensed separately; named credential callouts use Apex callout limits
Analytics on care program outcomesCRM Analytics for Health CloudNo — separate add-onHealth Cloud includes basic report builder; full CRM Analytics requires separate license
Caregiver portal (family member access)Experience Cloud for Health Cloud (same add-on)NoCaregiver access uses PersonAccount relationship records and sharing sets

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Inventory all personas and their cloud touchpoints. For every user type, document whether they are internal (care team) or external (patient, caregiver, marketing ops). Map each persona to the Salesforce cloud(s) they will interact with. This drives the license model.
  2. Confirm which clouds are in scope and which are purchased. Use the decision guidance table above to identify which clouds are bundled (Service Cloud, OmniStudio) versus which require separate purchase (Experience Cloud for Health Cloud, Marketing Cloud, CRM Analytics). Cross-reference against the customer's signed order form.
  3. Design the permission set license (PSL) assignment matrix. For every internal user role, determine whether they need Health Cloud PSL only, or also Health Cloud Platform and OmniStudio User PSLs. For external portal users, confirm Health Cloud for Experience Cloud PSL assignment. Document this matrix as a deliverable.
  4. Assess HIPAA BAA scope. Confirm whether the existing HIPAA BAA covers Health Cloud only, or also Marketing Cloud. If Marketing Cloud campaigns will include PHI, initiate the Marketing Cloud HIPAA BAA process with the Salesforce account team before any Health Cloud data flows into Marketing Cloud environments.
  5. Choose org topology. Evaluate single-org (preferred) versus hub-and-spoke based on data isolation requirements, regulatory obligations per business unit, and total cost of ownership. Document the decision rationale in an Architecture Decision Record.
  6. Validate the Experience Cloud site configuration. If a patient portal is in scope, confirm that the Experience Cloud site uses PersonAccount (not standard Contact) for member identity, that Sharing Sets are configured to give patients access to their own CareProgramEnrollee and CarePlan records, and that the Experience Cloud for Health Cloud PSL is assigned to all portal user profiles.
  7. Review the complete license model with legal and compliance. Before finalizing architecture, walk the HIPAA BAA scope and data flow diagram with the customer's legal and compliance team. Confirm that every cloud that will touch PHI is covered under the appropriate BAA.

Review Checklist

Run through these before marking work in this area complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. Experience Cloud for Health Cloud PSL is not auto-assigned to portal profiles — When an admin enables Experience Cloud for Health Cloud and creates the portal site, the Health Cloud for Experience Cloud permission set license is NOT automatically assigned to the portal user profile. Each portal user's profile must have this PSL explicitly assigned. Without it, Health Cloud components (Care Plan viewer, CareProgramEnrollee FlexCards) on the portal site throw "Insufficient Privileges" errors at runtime even though the site itself loads.
  2. PersonAccount is a one-way conversion in Health Cloud orgs — Health Cloud implementations almost always require PersonAccount enabled for patient identity. Once PersonAccount is enabled in a Salesforce org, it cannot be disabled. If a customer's existing Service Cloud org has Contact records not linked to PersonAccount, a migration plan must be in place before Health Cloud is layered on. Retrofitting PersonAccount into a live org with existing Account-Contact relationships requires a full data migration and relationship remapping.
  3. OmniStudio components fail silently when Health Cloud Platform PSL is missing — If a user has the Health Cloud PSL and the OmniStudio User PSL but is missing the Health Cloud Platform PSL, OmniScripts that read or write to Health Cloud-specific objects (EpisodeOfCare, CarePlan, ClinicalEncounter) will fail at the DataRaptor step with a generic "Record not found" or "FIELD_INTEGRITY_EXCEPTION" error rather than a clear permission error. This is the hardest PSL assignment bug to diagnose because the user can open the OmniScript UI successfully but the data operations silently fail.
  4. Marketing Cloud Health Cloud Connect requires the Connected App in both orgs — When configuring Marketing Cloud Health Cloud Connect, the Marketing Cloud connector package must be installed in the Health Cloud org AND the corresponding Connected App credentials must be configured in Marketing Cloud's Setup. If the credentials are configured only on the Marketing Cloud side (a common partial-setup mistake), the sync appears to work but data does not flow, and the error surfaces only in Marketing Cloud's Synchronization Dashboard — not in Salesforce Setup logs.
  5. Sharing Sets for Experience Cloud portal users do not support all Health Cloud object relationships — Sharing Sets (the mechanism that gives external portal users access to records they "own") work on direct lookup relationships from the portal user's PersonAccount. CarePlanTemplate and some ClinicalEncounter sub-objects are not reachable through Sharing Sets alone and require Apex sharing rules or OWD relaxation. Architects who design the portal access model assuming Sharing Sets cover all Health Cloud objects will discover the gaps in UAT, not design.

Output Artifacts

ArtifactDescription
Multi-cloud license modelTable of all Salesforce clouds in scope, whether each is bundled or a separate SKU, and per-user license cost implications
PSL assignment matrixGrid of every internal and external user persona against the permission set licenses they must receive, with rationale
Org topology ADRArchitecture Decision Record documenting single-org vs. hub-and-spoke decision with constraints, options considered, and chosen approach
HIPAA BAA scope diagramData flow diagram showing which clouds touch PHI and which BAAs must be in place for each flow
Experience Cloud site configuration checklistStep-by-step verification list for PersonAccount enablement, Sharing Sets, and PSL assignment for the patient portal

Package files