Usage-based Entitlement
A Usage-based Entitlement is a Salesforce Entitlement that tracks consumption of a limited support resource (cases, support hours, or any countable unit) and enforces a cap on how much support a customer can request under the contract.
Definition
A Usage-based Entitlement is a Salesforce Entitlement that tracks consumption of a limited support resource (cases, support hours, or any countable unit) and enforces a cap on how much support a customer can request under the contract. A platinum support contract might include 50 cases per year; once the customer files the 51st case, the entitlement no longer auto-matches and a Flow can prompt the customer for upsell or block the case. The Usage-based pattern is one of the standard variations of Entitlement Management.
Usage-based Entitlements are useful in two scenarios. Tiered support contracts where the higher tier includes a finite number of incidents instead of unlimited support. Time-banked support where customers buy a block of hours upfront and the org tracks remaining hours per case. The pattern is rare compared to time-based entitlements (a contract valid for 12 months regardless of case count), but it appears in B2B service deals where the vendor wants to limit support consumption while preserving the right to renew or upsell.
How Usage-based Entitlements track and enforce support consumption
Usage Types: Cases and Hours
Salesforce Entitlement Management supports two Usage Types out of the box. Cases-based tracks the number of cases filed under the entitlement. Hours-based tracks support hours consumed (typically captured through Time Entry records linked to cases). Custom usage types can be implemented through custom fields and Apex but are uncommon. The Usage Type is set at entitlement creation and cannot be changed afterward. Cases is the more common usage type; Hours is more common in professional services and consulting-style support contracts.
Maximum and current usage tracking
Each Usage-based Entitlement has two key fields. Per Incident Count Max (or Per Hour Max for hours-based) is the cap. Per Incident Count (or Per Hour Count) is the current usage. As cases consume the entitlement, the current count increments toward the max. When the current count equals the max, the entitlement has hit its limit. Subsequent cases either fail to auto-match or trigger a Flow that handles the overflow logic: upsell prompt, soft warning, or hard block depending on the business rule.
Per-Incident Counting Logic
For Cases-based entitlements, each case matched to the entitlement decrements the remaining count by 1. The decrement happens at case creation. Closing the case does not increment the count back; once consumed, the incident is spent. For Hours-based entitlements, the count decrements based on Time Entry records (or a custom field tracking minutes). The counting logic runs through standard Salesforce automation; no custom Apex required for the default Cases pattern.
Overflow handling: block, prompt, or graceful upsell
When a Usage-based Entitlement hits its cap, the platform behavior is configurable. Default: the entitlement no longer matches new cases, and the platform falls back to a different entitlement or treats the case as un-entitled. Hard block: a Validation Rule or Apex Trigger prevents case creation if the entitlement is exhausted. Soft prompt: a Flow on Case Create surfaces a notification to the user asking whether to consume an additional incident at extra cost. Most B2B service organizations use the soft prompt pattern: surface the limit, let the customer decide, log the override for billing.
Reporting on usage consumption
Usage-based Entitlements are reportable like any other entitlement. The Entitlement object exposes the current count, max count, and usage percentage. Most B2B service organizations build a dashboard tracking entitlement consumption by account and by quarter. Customers approaching their limit can be flagged for proactive outreach: "You have used 45 of 50 included cases this year; consider upgrading to unlimited support". The proactive outreach is one of the strongest retention plays in B2B service contracts.
Renewal and reset cycles
Usage-based Entitlements typically reset on contract renewal. The renewal creates a new Entitlement record (or resets the count on the existing record) with the contractual incident allowance for the new term. The reset can be automated through a scheduled Apex job, a Flow triggered by contract renewal, or a manual operations process. Without automation, the reset becomes a manual step that operations teams often miss, leading to customers locked out of support unexpectedly.
When to use Usage-based vs Time-based
Most Service Cloud orgs use time-based entitlements (contract valid for a fixed period with unlimited cases). Usage-based is the right pattern when the support contract specifically caps the number of incidents or hours. Pricing models that bundle support (Enterprise tier includes 100 cases per year, Premium tier includes unlimited) require the usage-based pattern. Subscription models with included incident counts as a value-add need it too. For most deployments, evaluate whether the contractual structure actually requires usage tracking before adopting the more complex pattern.
Creating a Usage-based Entitlement
Creating a Usage-based Entitlement is similar to creating any entitlement, with the addition of Usage Type and the cap fields. The setup takes 5 to 10 minutes per entitlement; bulk loads through Data Loader handle multi-account scenarios.
- Confirm Entitlement Management is enabled
Setup, Entitlement Settings, confirm the feature is enabled. Usage-based entitlements require the base Entitlement Management feature.
- Open the New Entitlement page
App Launcher, Entitlements, New. The form prompts for the account, entitlement process, start/end dates.
- Set the Usage Type
Pick Cases or Hours as the Usage Type. The choice is permanent for this entitlement.
- Set the cap (Per Incident Count Max or Per Hour Max)
Enter the maximum allowed: 50 for a Platinum tier with 50 included cases per year, 100 for a 100-hour support bank.
- Save the entitlement
Save. The entitlement is now ready to match cases and track consumption.
- Build the overflow handling Flow
Build a record-triggered Flow on Case Create that checks the entitlement's remaining count and surfaces a prompt or blocks creation when the entitlement is exhausted.
- Configure the consumption-tracking report
Build a report showing each entitlement's current usage and remaining capacity. Dashboard it for the operations team to monitor accounts approaching their limit.
- Plan the renewal reset
Decide how the entitlement resets at contract renewal: new entitlement record (preferred for audit), scheduled Apex job (efficient), or manual operations process (avoid for scale).
Cases or Hours. Determines which counter the entitlement tracks. Permanent after entitlement creation.
The cap on total cases (Cases usage type). Required for the platform to know when the entitlement is exhausted.
The cap on total hours (Hours usage type). Alternative to Per Incident Count Max depending on Usage Type.
The customer record the entitlement belongs to. Standard entitlement field, required regardless of usage type.
The contractual term. Cases consume the entitlement only within this date range.
- Usage Type cannot be changed after entitlement creation. Pick deliberately.
- The count decrements at case creation, not at case closure. Cases that are created and then deleted still consumed an incident.
- Without overflow handling, customers hitting their limit get no feedback. The entitlement silently stops matching, and the case has no entitlement context. Build the prompt or block deliberately.
- Renewal reset is not automatic. The operations team must reset the count or create a new entitlement at renewal time. Automate this path to avoid surprises.
- Hours-based entitlements depend on Time Entry records or custom field tracking. The platform does not auto-decrement hours; the case workflow must do the math.
Trust & references
Straight from the source - Salesforce's reference material on Usage-based Entitlement.
- Usage-based EntitlementsSalesforce Help
- Entitlement Management OverviewSalesforce Help
- Entitlement Object ReferenceSalesforce Developers
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 is a Usage-based Entitlement?
Q2. What happens with each interaction?
Q3. Why track utilization?
Discussion
Loading discussion…