Recently, I set up recurring milestones for a client, which gave me an opportunity to learn about this added feature from the Salesforce Winter 2014 release. Recurring milestones give you the option to add a new dimension to your service license agreements (SLAs), allowing the same milestone to recur rather than simply happening once.
Recurring milestones come in two options, 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, enter the entitlement process based on certain criteria, but are automatically created again when they are closed, if they still match the case criteria.
My client’s SLAs were fairly straight forward and have 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 between these. Here’s how they would fit in: First Response – one hour; update every one day; fix within 10 days.
Implementing recurring milestones
So, trusting that you understand how entitlement management works, here is how you implement 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, which could be any of the following:
- No Recurrence: This is the option we need if the milestone occurs once, such as our First Response and Fix milestones.
- Independent: This type of milestone start date is only based on the case criteria. If another milestone is created, the start date is based on when the last milestone completed.
- Sequential: This type of milestone start date is based on when the previous milestone’s target date was. For example, if a case enters a sequential milestone at 12:00 and its target date is an hour away at 13:00, but the milestone is actually completed at 12:05, the next milestone is created for 14:00, which is one hour away from the previous milestone’s target date, not the completed date.
Remember that the difference between the two options for recurring milestones (independent and sequential) is essentially the start date of the next automatically created milestone.
For the example in this article, we were going to use sequential, because it gives the support user more realistic and correct timings for the SLA.
Let’s say we are using an Independent Update Milestone, and it’s eight hours (same as business hours).
If a case comes in and enters the process at 9 a.m., and the support user completes the update milestone by 10 a.m., the next milestone’s target date will be 10 a.m. the next day, and if it is not completed by then, it becomes 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 5 p.m. on the second day.
I set up a quick test of the entitlement process just to see how this all worked when dealing with a case. Minutes are completely made up just for testing purposes.
The above is the outcome of my 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 happened yet, especially if in the client’s SLA, the first response is a longer time period than the update.
To combat this, I created a little work-around, which means when the first response milestone was created it then activated the update milestone. Here’s how I did that:
- I first created a checkbox field called First Response. FLS was set for everyone, as they would need to update it via a workflow. I did not add this to any pages because it was not needed. It was also defaulted to false.
- 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 it executes a workflow. which was then set to update this FirstResponse checkbox to True.
- 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 equals True.
In this example, this quick workaround ensures that the Update Milestone is used correctly.
Here is the finished project:
Here is what our entitlement looks like in action. As soon as the case is created with Priority 3, it enters the process. Here you can 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
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 found a reason that this this will mess anything up.
Ben McCarthy, also known as Salesforce Ben, is a certified Salesforce admin and developer. Ben has a wealth of experience in the Salesforce ecosystem as a Business Analyst, Head of CRM and Consultant.