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 – Salesforce.com
Creating Entitlement Processes – Salesforce.com
Comments: