What's a Coverage Schedule and how does it work?

A coverage schedule is a service calendar containing detailed time intervals that identify when a service request is expected to be worked.

Coverage schedules provide flexibility to define business hours and specific intervals during the year when different operating hours are offered. For example, you can define a specific interval such as a particular week or seasonal time period where you may extend service hours on specific days. You can also treat holidays or exceptions more specifically, such as offering shortened hours on some holidays, instead of a full day inclusion or exclusion.

To determine the due date and time for a milestone, time outside the specified intervals is skipped. For example, if your coverage schedule interval is 9:00 a.m. to 5:00 p.m. Monday through Friday, a milestone that started Friday at 4:00 p.m., which is due in 120 minutes, would be due 10:00 a.m. on Monday.

Coverage schedules can also contain holidays, nonworking times, or extended working hours, which identify days to be skipped or hours to be added when determining the due date. You must configure the coverage schedule exceptions before you create or modify a coverage schedule. In the previous example, when a milestone started 4:00 p.m. Friday and had 120 minutes until due, if Monday was identified as a holiday, the milestone would be due at 10:00 a.m. on Tuesday instead.

Here's how the application calculates the Due Date and Time Remaining fields that are displayed on the Service Request Milestone Details page:

• Due Date: The due date for a milestone is calculated using the schedule that's associated with the applicable entitlement or coverage rule. The schedule defines whether there are any hours of the day or week when the clock isn't running for the organization, such as evenings, holidays, lunch breaks, and so on.

  When a service request is updated, the application looks at the coverage rules and the associated schedule, calculates the date and time the milestone expires, and assigns the milestone to the service request. The milestone due date is calculated based on the time the milestone starts, which may not be the same as the time the service request was created. The application displays this due date for that milestone on the Service Request Milestone Details page.

  If the SR attributes change so that the milestone goes into a paused state, the clock stops running. The application captures the time spent on the milestone up until the milestone was paused, for future use. The due date for the milestone is no longer displayed, because it can't be determined until the milestone resumes the countdown. After the pause is lifted and the countdown resumes, the application recalculates the milestone due date. The recalculation is based on the original time you specified for that milestone when the SR was created, minus the cumulative time spent by the agent up to that point.

• Time Remaining: The Time Remaining field displays its value depending on whether the milestone is actively counting, paused, or overdue. The application doesn't show time remaining for milestones that are complete or canceled.

  When the milestone is actively counting down, the exact due date is known. The Time Remaining field shows an approximation of the amount of time between the due date and the current time. This approximation is expressed in the largest indivisible unit of time and rounded down. For example, if the current time is 3:00 PM and the milestone is due at 4:05 PM, the time remaining shows 1 hour. If the current time is 10:00 AM and the milestone is due the next day at 11:00 PM, the time remaining shows 1 day.

  When the milestone is paused and the due date can't be determined, the Time Remaining field identifies only the time left in the milestone. The time left is determined by calculating the total time specified in the coverage, minus the time spent so far. For example, a milestone that was set for 24 hours (based on the coverage rules), and that was active for 10.5 hours before it paused, will have 13.5 hours remaining for the duration of the time it's paused. The Time Remaining field uses the same approximation method as described for active milestones, so 13.5 hours is rounded down to show 13 hours. Again, the actual due date isn't in 13 hours, because it's unknown when the counting will resume and therefore how the schedule might affect the due date. The 13 hours is given as an approximation of the working time you will have once the milestone restarts.

  When the milestone is overdue but still not complete, the Time Remaining field shows how much time has elapsed since the milestone expired. The profile option ORA_SVC_SLA_INCLUDE_PAUSED_MINS_IN_TIMEREMAINING indicates whether this calculation considers paused minutes in the calculation.

  Excluding paused minutes ignores whether the milestone has paused after expiration, and results in a more accurate calculation of actual time elapsed and improved performance. Including paused minutes considers how much time was spent in the paused state after expiration and reduces the overdue time remaining value by that amount. This requires additional calculation, is less consistent with the calculation before expiration, and can impact performance.

  Note: Oracle recommends setting this profile option to N and starting with release 23D, all implementations will have the value set to N. You can then change the value to Y if you want for backward compatibility.

A schedule named 24 by 7 is preconfigured for all implementations. This schedule doesn't specify holidays or downtime, so the due date for a milestone that uses this schedule, is calculated without skipping any time.