Health Cloud fits when Salesforce has to understand health itself: patients or members with conditions, medications and coverage, enrollment in care programs, care teams, and networks of practitioners and facilities. If you need that clinical and coverage context next to service and outreach, the industry data model saves years of custom building. If your team mainly answers questions, logs requests and tracks customers who happen to be in healthcare, core Service Cloud usually does the job at lower cost and complexity.
What Health Cloud is today
Health Cloud is Salesforce's industry product for providers, payers, public health and, alongside related offerings, life sciences. It runs on the same platform as Sales Cloud and Service Cloud, so it inherits cases, the service console, Omni-Channel, Flow and reporting. The naming is in transition: salesforce.com still sells it as Health Cloud, while Trailhead and the developer guide now carry the Agentforce Health label, and Agentforce for Healthcare refers to the AI agents and prebuilt skills layered on top. Expect all three in proposals and documentation.
Salesforce markets capabilities such as a unified patient or member view, care management, provider network management, utilization management for prior authorizations and appeals, appointment and referral handling, and FHIR-based interoperability. Most of those rest on one thing that core Service Cloud does not have: objects designed for healthcare records.
The data model you are really buying
Patients and members are represented as person accounts, which appear as one record but are stored as a linked account and contact. Around that record, Health Cloud groups its objects into a few families, each aimed at a different kind of organization.
| Area | Example objects | Typical users |
|---|---|---|
| Clinical | Clinical Encounter, Health Condition, Care Observation, Medication Statement, Diagnostic Summary | Providers and care coordinators who need EHR context beside outreach and service |
| Care programs | Care Program, Care Program Enrollee, Care Program Goal, Care Program Team Member, Care Program Provider | Patient-support programs, payers and providers running structured, enrollable programs |
| Provider network | Healthcare Provider, Healthcare Practitioner Facility, Healthcare Provider Specialty, Healthcare Provider NPI, Healthcare Payer Network | Network management, credentialing and referral teams |
| Insurance and claims | Member Plan, Coverage Benefit, Purchaser Plan, Claim Header, Claim Line | Payer member services and benefits teams |
The clinical objects align with FHIR and are normally filled from an electronic health record through integration middleware. That point shapes every Health Cloud project: the EHR stays the clinical system of record, and Salesforce shows the slice of it that service, outreach and care-coordination staff need. Budget the integration as its own workstream rather than as a detail of the license.
Care programs deserve a separate look because they are often the deciding feature. A program such as medication adherence or a wellness plan has sponsors, eligibility rules, enrolled participants, goals and a team delivering it. Modeling that on core objects means inventing a structure Salesforce already ships.
When core Service Cloud is enough
Plenty of healthcare-adjacent organizations are served well by the core product. Service Cloud handles cases from email, web, messaging and phone, routes them, tracks response commitments and serves knowledge, none of which requires clinical data. Signs that you can stay on core Service Cloud:
- Your customers are clinics, labs or hospitals buying products, not individual patients receiving care.
- Support questions are about orders, shipments, billing, devices or account access rather than conditions or treatment.
- No one on the service team needs to see diagnoses, medications or coverage to resolve a request.
- You do not run enrollable programs with eligibility rules, sponsors and goals.
- Referrals and provider directories live in another system and do not need to be managed in Salesforce.
A synthetic-DNA manufacturer we worked with is a good illustration. It sits squarely in life sciences, yet its three-person support team needed case management, not a patient record, so core Service Cloud with six case record types and a knowledge base met the requirement without any industry data model.
Health Cloud earns its cost when several of the opposite are true: staff act on conditions, medications or coverage; you enroll people in programs; you manage practitioners and facilities as a network; or you already maintain custom objects that imitate those things and are tired of extending them.
HIPAA considerations to raise early
Salesforce describes Health Cloud as supporting HIPAA compliance, but no product makes an organization compliant on its own. Treat the points below as questions for your compliance, legal and security teams, not as legal advice:
- Confirm which Salesforce services your business associate agreement covers, and keep protected health information out of any feature or connected app outside that scope.
- Decide whether you need at-rest encryption, event monitoring or field history retention beyond the defaults, such as Salesforce Shield.
- Design sharing for minimum necessary access: a billing agent and a care coordinator should not see the same fields.
- Mask or remove real patient data before copying production into sandboxes used by developers or partners.
- Review what AI features, email templates and messaging channels could send or store, before switching them on.
Adding Health Cloud to an org you already run
The license is the easy part of bringing Health Cloud into an org that already runs Sales or Service Cloud; the effort sits in remodeling records that people and integrations depend on. A realistic order of work:
- Inventory what exists: custom patient, program or provider objects, the integrations writing to them, and the reports and automation reading them.
- Enable person accounts in a sandbox first. They cannot be turned off once enabled, and they change how contacts, duplicate rules and integrations behave.
- Settle on the standard objects or the older managed package components, and map each custom object and field to its Health Cloud equivalent.
- Plan the EHR, claims or eligibility integrations, including which system owns each field and how often data refreshes.
- Migrate in dependency order, reconciling counts after each load, then rebuild sharing, automation and page layouts around the new objects.
- Retire the old custom objects only after reports and integrations point at the new ones, and train staff on the new record pages.
Making the call
List the decisions your frontline staff make each day and the information behind them. If those decisions depend on conditions, coverage, program enrollment or provider networks, Health Cloud gives you a tested foundation that custom work will struggle to match. If they depend on orders, accounts and case history, invest in a solid core Service Cloud build and revisit the question when your use cases change. Abstrakt has been a Salesforce Consulting Partner since 2017, and we would rather talk you out of an industry cloud you do not need than build one you will not use.
