Milestone Type
A Milestone Type is the Salesforce metadata that defines how a specific milestone (First Response, Resolution, Escalation, custom) is detected as complete on a Case.
Definition
A Milestone Type is the Salesforce metadata that defines how a specific milestone (First Response, Resolution, Escalation, custom) is detected as complete on a Case. Each Milestone Type specifies which field change on the Case marks completion, what business rules constitute compliance, and which Milestone instances inherit from this type across multiple Entitlement Processes. Milestone Types are the reusable building blocks; individual Milestones in an Entitlement Process pick a Milestone Type and inherit its completion detection rules.
Milestone Types live under Setup, Service Setup, Milestone Types. The standard set ships with First Response (driven by case field changes that indicate the rep responded) and Resolution (driven by Case.Status changing to Closed). Custom Milestone Types support org-specific definitions: a Custom Field Validation milestone, a Customer Approval milestone, an Internal Quality Review milestone. The separation between Milestone Type (definition) and Milestone Instance (usage on a process) is what lets multiple Entitlement Processes share consistent completion detection logic.
How Milestone Types define reusable completion logic for SLA milestones
Standard Milestone Types and what they detect
Salesforce ships standard Milestone Types out of the box. First Response detects the rep responding to the customer; the platform looks at field changes like Case.IsClosed staying false plus activity logged that indicates outbound communication. Resolution detects Case.Status changing to a Closed-status value. The standard types cover the most common SLA targets; custom Milestone Types fill the gaps.
Custom Milestone Types and field-update detection
Custom Milestone Types let admins define completion via a specific field change. Configure the type with a Recurrence Type, then specify which field flipping to a particular value marks the milestone as complete. Examples: a Customer Approval Milestone Type triggered when Case.Customer_Approved__c becomes true; a Quality Review Milestone Type triggered when Case.QA_Review_Status__c becomes Passed.
The Milestone Type to Milestone relationship
Milestone Types are reusable across processes. One First Response Milestone Type can be referenced by Bronze SLA, Silver SLA, and Gold SLA Entitlement Processes; each process picks the same Milestone Type but applies different target times and actions. This separation is what makes the data model clean; the completion logic lives once on the Type, the timing and actions live per Process instance.
Recurrence Types: no recurrence vs recursive
Each Milestone Type configures a Recurrence Type. No Recurrence means the milestone fires once per case. Recursive means the milestone can fire repeatedly across the case lifecycle (a Follow-Up Within 24 Hours milestone that fires each time a new customer message arrives). Recursive milestones are powerful but easy to misconfigure; they can fire endlessly if the completion criteria do not properly reset. Use recursive sparingly.
Custom vs out-of-the-box trade-offs
Standard Milestone Types are the easy path. They detect common completion patterns without configuration and integrate cleanly with packaged Service Cloud features. Custom Milestone Types are more flexible but require careful field-detection setup; getting the detection logic wrong means the milestone never completes (false violations) or completes too aggressively (false successes). Default to standard; only build custom when the business case is specific enough to justify the configuration work.
Milestone Type metadata in deployment
Milestone Types deploy via Metadata API and Salesforce DX like any other metadata. Each environment needs the type defined before processes referencing it can deploy. Plan Milestone Type deployment as a prerequisite step in any Service Cloud rollout; missing a referenced type at deploy time fails the entire Entitlement Process deployment.
Common pitfalls
Three common mistakes. Building too many custom Milestone Types creates maintenance burden; consolidate where possible. Recursive types without clear reset logic cause infinite milestone instances. Custom Milestone Types that depend on multiple field combinations need explicit AND criteria; single-field detection misses the nuance.
Creating and configuring a Milestone Type
Milestone Type setup is straightforward: pick the standard type that fits or define a custom one with field-change detection. Each Entitlement Process then references the Milestone Type when adding milestones.
- Open Milestone Types
Setup, Service Setup, Milestone Types. The list shows existing types (standard plus any custom ones). Review what is already defined before creating new types.
- Create a custom Milestone Type
Click New Milestone Type. Configure Name, API Name, Recurrence Type, and Description. The Description is critical; future admins need to understand the completion logic without re-reading every field.
- Define field-change detection
Inside the Milestone Type, configure which field change marks completion. Pick the Case field and the value that flips to indicate the milestone is met. Custom Milestone Types often link to custom Case fields.
- Reference the Milestone Type from an Entitlement Process
Setup, Entitlement Processes. Edit a process. Add a milestone, pick the Milestone Type, configure target time and actions. The Type''s completion logic applies automatically.
- Test on a sample case
Create a case linked to an Entitlement that uses the process. Trigger the completion field change manually. Verify the milestone marks complete and Success actions fire.
No Recurrence (fires once per case) or Recursive (fires repeatedly). Use recursive sparingly to avoid endless milestone firing.
Field change on Case to specific value. Custom types support custom Case fields; standard types use Salesforce-defined detection patterns.
Standard types cover First Response and Resolution. Custom types cover everything else. Default to standard where possible.
Metadata API and Salesforce DX. Deploy Milestone Types before any process that references them.
- Recursive Milestone Types without reset logic fire endlessly. Configure completion resets carefully when using recursion.
- Custom field-change detection requires the field to actually flip during the case lifecycle. If the field is set at insert and never changes, the milestone never completes.
- Milestone Types cannot be deleted while referenced by an Entitlement Process. Remove all references before deleting.
- Deployment requires types to exist before the processes referencing them. Coordinate deployment order in CI/CD pipelines.
- Too many custom Milestone Types is a maintenance trap. Consolidate where possible; one well-named type beats five overlapping ones.
Trust & references
Cross-checked against the following references.
- Milestone Types OverviewSalesforce Help
- Milestones in Entitlement ProcessesSalesforce Help
Straight from the source - Salesforce's reference material on Milestone Type.
- Create a Milestone TypeSalesforce Help
- Milestone Recurrence TypesSalesforce Help
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 Milestone Type?
Q2. Why use milestone types?
Q3. What varies across entitlement processes?
Discussion
Loading discussion…