Health Cloud Setup
Health Cloud Setup is the collection of configuration steps and Setup pages an administrator uses to turn a standard Salesforce org into a working Health Cloud org.
Definition
Health Cloud Setup is the collection of configuration steps and Setup pages an administrator uses to turn a standard Salesforce org into a working Health Cloud org. It covers the prerequisites (person accounts, shared contacts, My Domain, Chatter), the Health Cloud managed package install, the permission set licenses and permission sets that grant access, and the patient-facing components like the Patient Card and care plans.
Health Cloud is the Salesforce product for healthcare payers, providers, and life sciences. It sits on the core platform and adds a clinical and member data model, FHIR-aligned objects, and purpose-built console apps. Most of that data model now lives as standard platform objects, and a managed package adds the extra objects, flow templates, Lightning components, and Apex triggers on top. Health Cloud Setup is the work of wiring all of those pieces together so care teams can open a record and see the full picture of a patient or member.
How a Health Cloud org gets stood up
Prerequisites before you install anything
Health Cloud has hard prerequisites that the org must satisfy before the managed package will install cleanly. You enable person accounts, since person accounts are the preferred way to represent an individual as a patient or a member. You allow shared contacts so one contact can be related to many accounts, which matters when a person is both a patient and a member of a household. You enable Chatter, and you register a My Domain, because several Health Cloud components and Lightning features depend on a custom domain being live. Skipping a step here usually surfaces later as a broken install or a component that will not load. Person accounts in particular are a one-way decision in practice. Once records exist on that model, moving off it is a heavy data migration, so treat the patient foundation choice as permanent. Salesforce documents these requirements as considerations to review before installation, and it is worth reading them in full rather than assuming a clean sandbox already meets them.
Installing the managed package
Most Health Cloud objects and APIs are built directly on the Salesforce platform, but the managed package adds capabilities you cannot get from the core objects alone. Installing it brings in additional Health Cloud objects plus flow templates, Lightning components, and Apex triggers that the console apps rely on. You install the managed package first, then you can layer optional unmanaged packages that extend Health Cloud with extra features for specific use cases. One detail to plan for is migration: certain objects in the managed package are superseded by equivalent objects on the core platform. Salesforce publishes a mapping between the managed package objects and their platform counterparts, which makes it easier for customers who started on the package to move to the platform data model over time. When you scope a new build today, prefer the standard platform objects where an equivalent exists, and only lean on the managed package object when there is no platform version. That keeps the org closer to where Salesforce is investing.
Permission set licenses and permission sets
Access in Health Cloud runs on two layers. A permission set license opens up a feature area that is not part of the base user license, and a permission set is the collection of object, field, and system permissions you actually assign to a user. The rule to remember is that every internal user must have at least the Health Cloud Platform permission set license to use Health Cloud at all. On top of that base, you assign role-specific permission set licenses and permission sets for what each team does. For example, you grant the Contact Center for Health Cloud permission set license to users who manage member records in the contact center. The Permission Sets page in Setup lists each permission set alongside the license it pairs with, so you can sort the License column to see which permission set matches which license. A common rollout mistake is assigning the permission set but forgetting the license behind it, which leaves users staring at features they cannot open. Assign both, and test with a real non-admin user before go-live.
The patient and member data model
Health Cloud organizes clinical and member information around a small set of records that hang off the patient or member. The person sits on an account, usually a person account, and child records carry the detail: conditions, medications, care plans, encounters, and the relationships between people in a household or care team. Much of this is now standard platform data, with the managed package adding objects where the platform does not yet have an equivalent. The model aligns with FHIR, the healthcare interoperability standard, which is what lets Health Cloud exchange records with electronic health record systems in a consistent shape. As an admin you spend real time deciding which fields belong on which object, how page layouts present them by role, and how reporting rolls up. The payoff is that a care coordinator or a service agent can open one record and read a coherent summary instead of hunting across disconnected objects. Getting the model right early avoids painful field reshuffles after users have built habits around the wrong layout.
Configuring the Patient Card
The Patient Card is the component that gives a care team a quick read on a patient without opening every related record. By default it shows contact details and key medical data such as medications and allergies, pulled from the objects that store the patient health data. Configuration is where you make it useful for your teams. You can remove fields nobody needs, and you can add fields from any object that has a reference to the patient record, which is a wide net. Because what a provider wants to see differs from what a patient service representative wants, you tailor the card so each role gets the summary that matters first. In current Health Cloud, the card and similar summary surfaces are often built with OmniStudio FlexCards, which gives you data-driven layouts without writing a custom component. Plan the card content with the actual clinicians and agents who will use it, since a card stuffed with every available field is as useless as one missing the field they check every call.
Care plans and ongoing administration
Care plans are the structured way a care team coordinates work for a patient over time. Rather than free-form notes, a care plan organizes goals, problems, and tasks so everyone touching the patient sees the same plan and the same next steps. Health Cloud Setup is where you enable and configure the care plan capability and any templates your program reuses for common conditions. Building a template for the conditions your population manages most is one of the higher-impact moves available, because it turns a blank page into a starting structure a care manager can apply and adjust. Administration does not stop at go-live. The Health Cloud managed package ships meaningful changes each Salesforce release, so reading the release notes every cycle keeps you aware of new objects, components, and deprecations. HIPAA alignment is also an ongoing program rather than a setting: Salesforce can provide a Business Associate Agreement and tools like Shield, while your team owns audit reviews, training, and access governance over the life of the org.
Stand up Health Cloud in order
Standing up Health Cloud follows a predictable order: satisfy the org prerequisites, install the managed package, grant the right licenses and permission sets, then configure the patient-facing components. Do these in sequence, because each step depends on the one before it.
- Meet the prerequisites
In Setup, enable person accounts, allow shared contacts, enable Chatter, and register a My Domain. Confirm each is active before moving on, since the package install assumes them.
- Install the Health Cloud managed package
Install the managed package from the install link Salesforce provides for your org. Install any optional unmanaged packages only after the managed package is in and verified.
- Assign licenses and permission sets
Give every internal user the Health Cloud Platform permission set license, then add role-specific licenses and permission sets (for example, Contact Center for Health Cloud) for what each team does.
- Configure the Patient Card and care plans
Tailor the Patient Card fields by role, then enable care plans and build templates for the conditions your population manages most. Test everything as a non-admin user.
The preferred model for representing a patient or member as an individual. Enable before installing the package.
The minimum license every internal user needs before any Health Cloud feature opens.
The set of fields shown on the card, drawn from any object that references the patient. Trim and extend per role.
Reusable goal, problem, and task structures applied to patients for common conditions.
- Assigning a permission set without its paired permission set license leaves users locked out of the feature.
- The person account decision is effectively permanent; switching the patient foundation later is a major data migration.
- Prefer standard platform objects over managed package objects where an equivalent exists, since Salesforce is mapping and investing there.
- Skipping a prerequisite like My Domain often shows up later as a component that silently fails to load.
Trust & references
Cross-checked against the following references.
- Health Cloud Managed PackageSalesforce
- Set Up Security and Permissions for Health CloudSalesforce
Straight from the source - Salesforce's reference material on Health Cloud Setup.
Hands-on resources to go deeper on Health Cloud Setup.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What customer experience metric would Health Cloud Setup help improve?
Q2. How does Health Cloud Setup help support agents be more productive?
Q3. Which Salesforce Cloud includes Health Cloud Setup as a key feature?
Discussion
Loading discussion…