Consultants / Admins

Using Recurring Milestones in Salesforce

By Ben McCarthy

Project Background

So I recently set up Recurring Milestones for a client of mine which gave me a good opportunity to learn about this newly added feature from Winter 14. The principle behind recurring milestones is that it gives you the option to add a new dimension to your SLA’s allowing the same milestone to recur rather than simply happening once.

Recurring Milestones come in two flavours, Independent and Sequential, but I’ll talk about these in detail a bit later. Essentially they are no different from standard milestones, they are created in the same way, they enter the Entitlement Process based on certain criteria but of course are automatically created again once they are closed if they still match the case criteria.

My clients SLA’s were fairly straight forward and have currently been using First response and Fix milestones to monitor timely response and fix times for customers. The requirement was to add an Update milestone to fit in between these. This would fit in like so.

First Response – 1 hours

Update every 1 day

Fix within 10 days.

Implementing Recurring Milestones

So trusting that you have a good background in understanding how entitlement management works, here is how you go about implementing Recurring Milestones.



As I said before Recurring Milestones are created in the exact same way as previous Milestones. The only difference is we need to set the Recurrence type.

No Recurrence – So this is the option we need if the milestone occurs once, e.g. our First Response and Fix milestones.

So it took me a while to understand the difference between the two options for recurring milestones as everyone seems to explain it with huge blocks of text and long needless examples but essentially the difference is the start date of the next automatically created milestone.

Independant –  This type of Milestones start date is not based on anything other than the case criteria. If another milestone is created then the start date is based off when the last milestone completed.

Sequential – This type of Milestones start date is based on when the previous milestones target date was. For example if a case enters a Sequential milestone at 12:00 and its target date is an hour away, so 13:00 but actually the milestone is completed at 12:05 then the next milestone is created for 14:00 which is 1 hour away from the previous milestones target date NOT the completed date

For this project we were going to use Sequential. The reasoning for this is that it gives the support user more realistic and correct timings for the SLA. Follow this example to see the logic behind it for using sequential.

Say we are using an Independant Update Milestone and  its 8 hours (same as open business hours)

If a case comes in and enters the process at 9am and the support user completes the update milestone by 10am the next milestones target date will be 10am the next day, and if it is not completed by then it will be a violated case. This isn’t correct. The next target date should be daily and therefore at the end of the second day. If we were using Sequential this would come in at 5pm on the second day.


So I set up a quick test Entitlement process just to see how this all worked when dealing with a case.  Minutes are completely made up just for testing purposes.


So the above is the outcome of me creating a case using the Entitlement process. One thing immediately stood out to me – I don’t want the update milestone running in the background when the first response hasn’t even taken place. Especially if in the clients SLA’s the first response is a longer time period than the update.

To combat this I created a little work around that meant once the first response milestone was created it then activated the update milestone.

1. I first created a checkbox field called FirstResponse. FLS was set for everyone as they would need to update it via a workflow, I did not add this to any pages though as it was not needed. It was also defaulted to false.

2. I created a Success Action on the First Response Milestone. This essentially means that whenever the milestone has been completed, whether violated or still within SLA then execute a workflow. This workflow was then set to update this FirstResponse checkbox to true.

3. Criteria needed to be added to the Entitlement process to make sure the Update milestone only appears when it meets normal case criteria AND the FirstResponse field = True.

This quick workaround ensures that the Update Milestone is used correctly in this example.

Completed Project

And here is the finished product!


So as a quick working example here  is what our entitlement looks like in action.  So as soon as the case is created with Priority 3 it enters the process.Here you can clearly see that our recurring milestone has not yet been activated due to first response awaiting completion.


Here you can see exactly what was expected. The first response milestone has been completed setting off the workflow to update the FirstResponse field and our recurring milestone has entered the process


Following on from this you can see what happens with our Sequential Recurring Milestone once we update the original one. It has automatically created another using the target date of the previous ( 15:00 + 10 minutes = 15:10 target date)


Finally the case has been closed and resolved and the case leaves the entitlement process. Currently the update milestone that still needs to be completed will just run down to 00:00 and will not affect the successful SLA fulfilment. Although it does look a little messy I have not yet found a reason that this this will mess anything up.


Useful Links

Official Winter 14 Release Notes on Recurring Milestones –

Creating Entitlement Processes –

The Author

Ben McCarthy

Ben is the Founder of Salesforce Ben. He also works as a Non-Exec Director & Advisor for various companies within the Salesforce Ecosystem.


    August 18, 2014 1:13 pm
    Is that possible to run the same milestone again. Example : i have milestone for first response when status eq new. Now 1st milestone is running. The user completed the miles stone. Now status is changed to inprogress. Again another user is changed the queue and updated the status as new. Will that milestone run again . ?
    Scott Fletcher
    February 22, 2016 11:40 am
    Useful overview of this topic, thanks!
    Einat Avraham
    November 21, 2016 9:17 am
    Thank you, this was really helpful!! Einat
    December 06, 2016 4:58 pm
    Ben... I am using 2 milestones. The 1st is non-recurring and the 2nd (update customer) is a sequential milestone. When the 1st milestone is complete, a custom checkbox is set to true and I update a number field that just increments each time a milestone runs. The milestone criteria for the 2nd looks for true in the custom checkbox field and looks for an increase in the count (i have a checkbox for this) and as long as that's true... I expect to see the 2nd milestone recurring again after it has been met, but it only reoccurs once no matter what I do. What do you recommend?
    October 25, 2018 10:14 pm
    i tried this, but it doesn't work properly. I am using 2 non recurring milestones, when a case is created i only see the first milestone. When the first milestone is complete, a custom checkbox is set to true. The milestone criteria for the second looks for true in the custom checkbox field. I see the second milestone but the time has been running even when the criteria for de second milestone has not been met. am I missing something? what do you suggest?
    Hemant Singh Rana
    September 25, 2019 11:42 am
    Best document ever seen on Milestone. So easy to understand. Thanks a lot!
    Ben McCarthy
    September 25, 2019 12:09 pm
    Thanks so much Hemant! This was our first post ever :)

Leave a Reply