Special cases for request-based service target processing

The following are the special cases for request-based processing:

• Service target group processing for request-based service targets
• Reference start time for request-based service targets
• Reopening of requests for request-based service targets
• Reference goals on the application form for request-based service targets

Service target group processing for request-based service targets

Service target groups are a special feature that works only for request-based service targets. This scenario applies when fields change on the incident or change request so that the terms and conditions of the attached service target do not apply. A new service target from the group is attached, and the date values are re-calculated based on the inherited values from the previous group member.

This can happen if there are different service targets for high, medium, and low priority requests of a certain category, and these service targets are grouped under one service target group. For example, if an incoming ticket has a high priority and a high service target is attached and starts processing, when time elapses and the request changes to a low or a medium priority, a new service target is attached. However, the new service target inherits the start and excludes times from the first service target and does not behave as if it just started.

The following examples illustrate the most common scenarios that might occur. 

Example 1

In this example, when service target 200 attaches, it inherits the start time from service target 100. Milestones are removed from the service target. Milestones are calculated from service target 200 to start from the start time of service target 100.

Example 2

In this example, when service target 200 is attached, then service target 100 is an Exclude state. Milestones are removed from service target 100. Service target 200 is in an Exclude state with the down time inherited from service target 100. When service target 200 changes from pending, milestones from service target 200 are calculated to start from the start time of service target 100 with an additional offset of the time both service targets were in a pending state.

Example 3

In this example, when service target 200 attaches, it inherits the start time from service target 100. Milestones are removed from service target 100. Milestones from service target 200 are calculated to start from the start time of service target 100, which in this case is the same time as the start time of service target 200. In this scenario, nothing is inherited by service target 200.

Example 4

In this example, when service target 200 is attached, it inherits the start time from service target 100, and the up time and down time is calculated by service target 100. The measurement record is removed from service target 100. Milestones are removed from service target 100. Milestones are calculated from service target 200 to start from the start time of service target 100, with an offset from the down time calculated by service target 100. The time might appear to be inconsistent because the down time was calculated using the business time from service target 100. If the business times used are not matched, the time might seem unpredictable. To be sure that the time calculation is done correctly, review the time value in the SLM:Measurement form.

Example 5

In this example, the service target 100 has been processed and closed. When service target 200 is attached, it inherits the start time from service target 100, and the up time and down time calculated by service target 100. The measurement record is removed from service target 100. The "dead" time between the service target's working time service target is calculated as an Exclude time using the business time tag from service target 100. Milestones from service target 200 are calculated to start from the start time of service target 100, with an offset from the down time calculated by service target 100 (Exclude time and the "dead" time). The time might appear to be inconsistent because the down time was calculated using the business time from service target 100. If the business times used are not matched, the time might seem unpredictable. To be sure that the time calculation is done correctly, review the time value in the SLM:Measurement form.

Example 6

In this example, the service target 100 has been processed and closed.When service target 100 is attached, it inherits the start time from service target 100 and the up time and down time calculated by service target 100. The measurement record is removed from service target 100. The "dead" time between the service target's working time service target is calculated as an Exclude time using the business time tag from service target 100. Milestones from the new service target 100 are calculated to start from the start time of the original service target 100, with an offset from the down time calculated by service target 100 (Exclude time and the "dead" time). 

Example 7

In this example, the service target 100 has been processed and closed. At the same time the ticket is changed so that service target 200 is attached in a closed state. When service target 200 is attached, it inherits the start time from service target 100 and the up time and down time calculated by service target 100. The measurement record is removed from service target 100. Milestones are not created from the new service target 200 because it is closed. Service target 200 is evaluated using the calculated time from service target 100, but using the goal from service target 200.

Example 8

In this example, the service target 100 has been processed and closed. Later, service target 200 is attached in a closed state.When service target 200 is attached, it inherits the start time from service target 100 and the up time and down time calculated by service target 100. The measurement record is removed from service target 100. Milestones are not created from the new service target 200 because the service target 200 is closed. Service target 200 is evaluated using the calculated time from service target 100, but using the goal from service target 200.

Reference start time for request-based service targets

In cases when a ticket is submitted into the system later than when it was requested, such as for a phone request, the service target needs to be effective from an earlier time. When the service target starts, the start time is taken from a field on the application form that stores the time when the "Start When" measurement criteria is met. If this field is blank, it takes the system time as the start time if the "Start When" measurement criteria are met.

To specify the Start Time for the service target, it must be configured in the SLM:ConfigDataSource form. Specify the field name that holds the start time information from the application form in the Start Time for Time-Based service targets field on the SLM:ConfigDataSource form.

Measurement calculation uses the contents of this field as the Start Time of the measurement instead of timestamp of the ticket submission.

Reopening of requests for request-based service targets

Reopening a request is the default behavior in request-based processing and does not need to be configured. If a request is resolved, or meets its stop condition, then its measurement goes to a closed state with either a Met or a Missed status.

If the request is opened again, that is opened after being resolved or closed, it is moved back to an open state, and a new measurement record is created that finds a previously closed measurement record and inherits its elapsed times and start time. The old record is deleted and the new measurement record becomes active. The old stop time is used to calculate the exclude time or the "dead time" between the measurement records. This time is not counted towards the completion of the SLO. The new "dead time" will be added to the previous Due Date on the new measurement record when reopening the service target.

If this behavior is not wanted, you can set "Allow Service Target to Re-Open" to "No" in the service target.

For additional information, see Resetting goals for the same request.

Reference goals on the application form for request-based service targets

A service target can use a goal specified on the application form instead of on the service target. This goal can be time elapsed in seconds, or a due date and time. This way the goal can vary based on the request that the service target attaches to. This is particularly useful for a change request where a planned completion date of the request can be the goal for a service target instead of a fixed goal. For Reference End Goal for Request-Based service targets, the downElapsedTime field in the SLM:Measurement form is not calculated.

The Association filter is executed when the terms and conditions qualification is met. An entry is created in the SLM:Measurement form with MeasurementStatus set to Attached. Because there is always a status for an availability service target, the status changes to the appropriate state and the OverallStartTime is set to the current time.To specify the Reference Goal for the service target the administrator must configure it in the SLM:ConfigDataSource form by setting the Reference Goal for Time-Based service targets or Reference End Goal for Time-Based service targets field. This configuration can be turned on or off per service target by using the Use Goal defined on the Application Form field on the Goal tab of the service target. Exclude qualification is not supported for Reference Goals on the application form for request-based service targets. Using exclude qualification may result in unknown behavior.

The Up filter is executed when the CI is available. When the qualification is met, UpStartTime is set with current time, and MeasurementStatus is set to In Process.

The unavailability filter is executed when the CI is unavailable. When the qualification is met, zD_UpStopTime is set with the current time. The Unknown filter is executed when the NOT (Availability) AND NOT (Unavailability) qualification is met, and MeasurementStatus is set to Unknown. The unavailable time is updated.

• Leaving an Unknown state leaves the CI either available or unavailable. The appropriate filter executes to update the measurement record with the status and time.
• NotDown filter is executed when the NOT (Unavailability) qualification is met, and zD_DownStopTime is set with the current time.
• In all these scenarios, a MeasurementChild record is created for each change in states. This record is required for SLA compliance calculations and to provide data for the dashboard.