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.