We noticed recently that the "elapsed time" of a milestone does not seem to exclude the time that the entitlement process was stopped. To us, that's a clear bug but I would like to know if other people have also seen this behavior and what their solution was to have the correct elapsed time.

First test: impact of stopping the clock on the "Elapsed Time"

Milestone start date:       25/02/2015 09:34
Target response time:       10 mins
Target Date                 25/02/2015 09:44
Stopped Since:              25/02/2015 09:35
Restarted at:               25/02/2015 09:47
Completed milestone at:     25/02/2015 09:47
Elapsed time after close:   13 mins
Violation                   NOT CHECKED! (although the elapsed time is greater than the target response time...)
Target Date                 25/02/2015 09:56 (moved by the time process was stopped)

so, the clock being stopped or not does not influence the elapsed time while it should... Also, as long as the milestone is not yet completed, you have the "time remaining" which IS being influenced by the entitlement being stopped or not

Second test (as a sanity check... you would start doubting everything): impact of the business hours on the "Elapsed Time"

Case opened outside of business hours
business hours of day of testing: 10:00 to 10:05 AM

Start Date                  25/02/2015 09:54 AM
Target Date                 26/02/2015 00:55 AM
Target Response (Mins)      60
Completion milestone at:    25/02/2015 10:06
Elapsed time:               5 mins

so here, the business hours DO have impact on the elapsed time

could someone confirm this buggy behavior please and let me know if there are workarounds?

  • so far, no news from support apart from they saying that there is an idea for this... To me, there should be a clear distinction between a bug and an idea :) so for me, case NOT closed yet...
    – KoenVM
    Commented Mar 4, 2015 at 6:07

2 Answers 2


In Winter 16, The "Stopped time" and "Actual Elapsed Time" will be available on the Milestone entity. It will work with Business hours too.


Ok... turns out that the elapsed time is simply the DIFF in businesshours between the milestone completion date and start date.

It doesn't take into account the time when the entitlement was stopped.

I got this confirmed today by Salesforce support.

What I did as a workaround:

  • created a custom object "Completed Milestone" with basically the same fields as the standard CaseMilestone object
  • on this custom object though, I have 2 elapsed time fields: "Gross Elapsed Time" which is the same as the standard elapsed time and "Net Elapsed Time"

The "Net Elapsed Time" is the regular elapsed time minus the time that the entitlement process was stopped.

This time is calculated as follows: enter image description here

These custom "Completed Milestone" records are then created every time a milestone is completed. Since you can't put a trigger on CaseMilestone, I created a field on Case level "Sync Completed Milestones" which is a datetime field and which I fill with datetime "now()" on the success actions of the entitlement milestones.

Then, there's a trigger on Case on the changing of that datetime field to enter my milestone sync code where I copy the actual fields and do this "Net Elapsed Time" calculation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .