Coverage
Coverage in Salesforce describes what support or protection a customer is entitled to and under what terms.
Definition
Coverage in Salesforce describes what support or protection a customer is entitled to and under what terms. The meaning shifts with the cloud you are in. In Service Cloud it is the entitlement check that decides whether the person who logged a case has a right to support, and which response and resolution clocks apply. In Health Cloud and Financial Services Cloud it refers to the records that capture a member's plan enrollment or a policy's protections.
Across all of these, coverage answers one question: what does this customer have access to, and on what terms. In Service Cloud that drives whether an agent should help and how fast. In the industry clouds it drives whether a benefit applies or a claim should be paid. Salesforce does not ship a single object literally named Coverage, so the exact object depends on the product in play.
How coverage works across Service, Health, and Financial Services Cloud
Coverage in Service Cloud: the entitlement check
In Service Cloud, coverage is shorthand for the entitlement check that runs around a case. An entitlement represents the support an account or contact is eligible to receive. It can be based on an asset, a product, or a service contract. When an agent or automation looks up the right entitlement for a case, the question being answered is plain: does this customer have active, in-date support, and what are the agreed response times. The entitlement sits on the case through the Entitlement Name lookup. Once it is set, the entitlement process attached to it begins, and milestone clocks such as first response and resolution time start counting. If no valid entitlement is found, the case is effectively uncovered and usually routed to a triage queue. This is why the entitlement lookup is the load-bearing piece of a service operation. A wrong assignment means the SLA timer runs against the wrong terms, and reporting on compliance becomes unreliable.
Entitlements, service contracts, and where they connect
An entitlement reflects the terms written into a service contract. A single service contract can carry many entitlements, linked through the Entitlements related list on the contract or the Service Contract lookup on each entitlement. The service contract lives at the account level and represents the broader agreement, such as gold support purchased for a year. The entitlement is the more granular grant that a case actually matches against. Entitlements carry their own dates and counters. Start Date and End Date bound the period of valid support. Remaining Cases and Cases Per Entitlement can cap how many cases the grant covers. The Entitlement Process lookup points to the timeline of milestones that should run. Because these fields gate real support behaviour, teams keep them clean through integration with the renewal or provisioning system rather than manual edits. When a contract renews, the entitlement dates should move with it so coverage does not lapse between terms.
Entitlement processes and milestones
An entitlement process is a customizable timeline of the support steps a case must hit. On its own it is an empty frame; milestones give it meaning. A first response milestone records how quickly the team should reply, and a resolution time milestone records how quickly the case should be closed. These are the parts customers feel as the service level agreement. Milestones support different recurrence types. Independent milestones occur whenever their criteria are met on the case. Sequential milestones occur on repeat as the case moves through its steps. Milestone actions let you fire automated work, such as an email warning agents that a deadline is near. There are guardrails worth knowing. You cannot add milestones to support records without an entitlement process, and after a process is activated you cannot delete its milestones or add milestone actions. The supported path is to create a new version of the process with different settings and apply that version to existing entitlements.
Coverage in Health Cloud: MemberPlan and CoverageBenefit
Health Cloud does not use a bare object called Coverage. The coverage concept is split across a few standard objects. MemberPlan represents the insurance coverage held by a member or subscriber, with the enrollment details that say which plan applies and for what period. It is the anchor record a care team checks to confirm a patient is covered before scheduling care. Sitting under that, CoverageBenefit represents the specific benefits a member has under the plan, and CoverageBenefitItem breaks those down further into individual items and limits. Together these form the benefits verification data model that answers questions like is this procedure covered and what is the remaining limit. PlanBenefit and PlanBenefitItem describe the standard benefits a purchaser offers across members, which the per-member CoverageBenefit records draw from. So when a Health Cloud team talks about coverage, they usually mean the combination of a MemberPlan plus its CoverageBenefit records, not a single field.
Coverage in Financial Services Cloud: InsurancePolicyCoverage
Financial Services Cloud handles insurance coverage through the InsurancePolicyCoverage object. It represents the protections a policy provides, such as a liability or property coverage line, and it joins to InsurancePolicy and to the insured assets through InsurancePolicyAsset. Underwriters and claims adjusters work against these records to decide what a policy protects and how a claim should be settled. Around it sit related objects. InsurancePolicy captures the policy type, whether auto, home, life, or annuity. Claim represents the claims raised against the policy. InsurancePolicySurcharge holds charges calculated for the policy and its coverages. The practical takeaway is the same as in Health Cloud: coverage is a model of connected records, not one object named Coverage. Naming this precisely matters during build and integration work, because field mappings and validation rules reference the real API names rather than the everyday word.
Reporting on coverage and why it pays off
Each cloud turns coverage into reports that operations teams live by. In Service Cloud the high-value reports show uncovered cases as a triage list, case volume by entitlement to see which contracts drive load, and SLA attainment so leaders can prove the team is meeting agreed response and resolution times. Cases Per Entitlement is also a quiet renewal signal, since heavy users of a support grant are strong upsell and retention candidates. In Health Cloud, coverage reporting centres on member enrollment, benefit utilization, and gaps where a member lacks coverage they should have. In Financial Services Cloud, coverage-level reporting feeds claim frequency and severity analysis that actuarial and underwriting teams use to price risk. The common thread is that coverage data is rarely just operational. In the regulated clouds it is part of compliance, so teams apply Field Audit Trail and tighter sharing than the platform defaults give you.
Coverage versus Entitlement: clearing up the overlap
The word coverage and the word entitlement get used interchangeably in Service Cloud conversations, which causes confusion. Entitlement is the actual standard object that holds the support grant. Coverage is the broader idea of whether a case is covered and on what terms, realised through that entitlement and its process. So an admin configures entitlements, but a manager asks whether a customer has coverage. Both are talking about the same chain of records. The overlap widens when industry clouds enter the room. There the word coverage maps to MemberPlan, CoverageBenefit, or InsurancePolicyCoverage depending on the product, and none of those touch Service Cloud entitlements. A cross-functional meeting can stall simply because two people mean different objects by the same word. The fix is cheap: state the cloud first, then the object, before debating behaviour. Saying Service Cloud entitlements or Health Cloud MemberPlan removes the ambiguity in one sentence.
How to set up coverage with Service Cloud entitlements
To make Service Cloud coverage work, you enable entitlement management, then build the records that let a case find its entitlement and start the right SLA clocks. This is the configure-feature path an admin follows in Setup.
- Enable entitlement management
From Setup, open Entitlement Settings and turn on entitlements. Choose whether the Entitlement Name lookup appears on cases and whether agents can edit it, so the coverage link can be set during case creation.
- Build an entitlement process with milestones
In Setup under Entitlement Management, create an entitlement process, then add milestones such as first response and resolution time. Set the recurrence type per milestone and add milestone actions for warnings or escalations before you activate the process.
- Create service contracts and entitlements
Create a service contract on the account, then add entitlements that reflect its terms. Set Start Date, End Date, and the Entitlement Process lookup so each grant has valid dates and a timeline to run.
- Assign the entitlement to cases
Set the entitlement on the case, manually or through Flow or Apex on case create. Once the lookup is populated, the entitlement process activates and the milestone clocks begin counting against that customer.
Decide whether entitlements are granted by asset, product, or service contract. This shapes how a case matches the right coverage.
Choose independent or sequential recurrence per milestone so the timeline matches how your support steps actually repeat.
Standardize on one assignment method, Flow or Apex, rather than both, to avoid conflicting entitlement assignments.
- You cannot add milestones to a case without an entitlement process; the process is what applies them.
- After an entitlement process is activated you cannot delete its milestones or add milestone actions; create a new version instead.
- If no valid in-date entitlement matches, the case is uncovered and SLA clocks will not start, so build a triage path for those cases.
Prefer this walkthrough as its own page? How to Coverage in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Milestones (Entitlement Management)Salesforce
- Entitlement Object ReferenceSalesforce
Straight from the source - Salesforce's reference material on Coverage.
- Service ContractsSalesforce
- MemberPlan Object (Health Cloud)Salesforce
- InsurancePolicyCoverage Object (Financial Services Cloud)Salesforce
Hands-on resources to go deeper on Coverage.
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. In Service Cloud, what question does Coverage answer when a Case is created?
Q2. How does the entitlement match that drives Service Cloud Coverage run?
Q3. What does Coverage mean in Health Cloud or Insurance Cloud, in contrast to Service Cloud?
Discussion
Loading discussion…