If you’re an ISV partner or developer building packages that integrate with or extend Salesforce Health Cloud, you’ve probably noticed a major shift in how Health Cloud is provisioned. The old standalone managed package approach has been officially deprecated for new setups, and Health Cloud functionality is now baked directly into the core Salesforce platform.
This guide gives you the exact, battle-tested steps the community is using right now to spin up a fully functional Health Cloud environment in minutes — perfect for testing package compatibility, building extensions, or running quick PoCs. At Genetrix, we’ve set up dozens of Health Cloud environments for ISV clients using exactly this workflow.
Why the Old Approach No Longer Works (and Why 2026 Is Better)
Until mid-2024, most developers relied on installing a separate Health Cloud managed package. That era is now officially behind us for new implementations.
Starting with the Summer ’24 release, Salesforce officially advised all new customers to skip installing the managed package entirely. The features that previously required it — Intelligent Appointment Management, the Patient API, and core relationship objects — have been migrated to standard platform objects like AccountAccountRelation, AccountContactRelation, and ContactContactRelation. Health Cloud is now enabled through feature flags, not a package install.
Option 1: Fastest for Partners — Use Demo / Dev Station Templates
If you have Partner Portal access, the absolute quickest path is the official Health Cloud template inside Demo Station or Dev Station.
- Log into the Salesforce Partner Community.
- Navigate to Demo Station or Dev Station.
- Search for the Health Cloud template and select it.
- Spin up the org — it will be pre-configured with Health Cloud already enabled.
- Go to Setup → Feature Settings and enable only the specific Health Cloud features your package needs.
Option 2: Best for Developers — Create a Scratch Org (Recommended Method)
Traditional Developer Edition orgs with Health Cloud pre-installed are no longer available. The modern, recommended approach for development and testing is a scratch org with the correct feature flags. This is the method we use at Genetrix for all ISV compatibility work.
Step 1 — Create your scratch org definition file
In your project folder, create config/healthcloud-scratch-def.json:
config/healthcloud-scratch-def.json
{
"orgName": "Health Cloud Test Org 2026",
"edition": "Enterprise",
"features": [
"HealthCloudAddOn",
"HealthCloudForCmty",
"HealthCloudMedicationReconciliation",
"HealthCloudPNMAddOn",
"ServiceCloud"
]
}
Pro tip: Only include the features your package actually uses. HealthCloudAddOn is the base — everything else is optional. Keeping the org lean makes it faster to provision and conserves your Dev Hub’s daily scratch org allocation.
Step 2 — Run the Salesforce CLI command
Terminal
# Create the scratch org sf org create scratch \ --definition-file config/healthcloud-scratch-def.json \ --alias hc-test-org \ --duration-days 30 \ --target-dev-hub YOUR_DEV_HUB_ALIAS # Open it in your browser sf org open --target-org hc-test-org
2026 Quick Setup Checklist
- Partners — Start with Demo/Dev Station templates for the fastest spin-up with zero CLI config.
- Developers & ISVs — Use scratch orgs with
HealthCloudAddOnas the base feature flag. - No package install required — Managed package deprecated for new setups from Summer ’24 onward.
- Keep feature flags lean — Only add what your package actually references to stay within Dev Hub limits.
- Production / full orgs — Request Health Cloud licenses via your Account Executive or Salesforce support.
- Migrating from a legacy org? — Check for old namespaced objects and follow the Salesforce Help migration docs.
Frequently Asked Questions
No — for new setups. Since Summer ’24, Salesforce has officially advised new customers to skip the managed package. All core functionality is now enabled through platform features. If you’re working with an existing org that was provisioned before Summer ’24, the legacy namespace-based objects will still be present and need to be handled during migration.
Start with HealthCloudAddOn — it’s the base and required for all Health Cloud functionality. Only add HealthCloudForCmty (Community/Experience Cloud integration), HealthCloudMedicationReconciliation, or HealthCloudPNMAddOn (Provider Network Management) if your package specifically uses those capabilities.
Yes — this is the officially recommended method for ISV partners and developers. It integrates cleanly into CI/CD pipelines and lets you share the same definition file across your entire team, guaranteeing everyone works against an identical environment.
For brand-new scratch orgs there is nothing to migrate. For existing orgs that used the old managed package, the key change is that relationship objects previously under the Health Cloud namespace now map to standard objects like AccountAccountRelation and ContactContactRelation. Refer to the latest Salesforce Help documentation for the full namespace-to-core object mapping guide.
This depends on your Dev Hub’s edition and license tier. Developer Edition Dev Hubs have a lower daily limit than Enterprise or Unlimited orgs enabled for packaging. You can check your current usage and limits with sf org list limits --target-org YOUR_DEV_HUB_ALIAS.
Building on Health Cloud? Let’s Talk.
Genetrix is a certified Salesforce consulting partner with hands-on experience across Health Cloud implementations, ISV package development, and DevOps setup. If you’re planning a Health Cloud rollout or need to optimise an existing environment, our team is ready.
