The reset of the due date does not happen when the SVTs involved are members of the same service target group. Following are the details for testing the reset functionality:

1) the data source is configured with a reset condition based on Assigned Group*+ field, which is also defined for the 'Field Containing Record Assignment' field

2) two service targets are defined to the same service target group
     SVT1 - TnC 'Urgency' = "1-Critical"
     SVT2 - TnC 'Urgency' = "2-High"

no SVT group
==========================================
- submit incident to attach SVT1 and assign to Group A
   due date mm/dd/yyyy
- update incident to detach SVT1 and attach SVT2
   due date is reset
- update incident and reassign to Group B
   due date is reset


SVT group
==========================================
- submit incident to attach SVT1 and assign to Group A
   due date mm/dd/yyyy
- update incident to detach SVT1 and attach SVT2
   same due date
- update incident and reassign to Group B
   same due date but the expectation is that there will be a reset with reassignment of the group

When the SVTs are not in a service target group, there is a separate SLM:Measurement record created for each attach for either SVT1 or SVT2. When the SVTs are in a service target group, there is a single SLM:Measurement record corresponding to the current condition to attach either SVT1 or SVT2. In both cases, there is a separate SLM:TeamMeasurement record for each reassign to a different group.

Legacy ID:KA372090

This problem was initially reported as a defect in SW00431892. After a review of the code and confirmation with dev engineering, it has been confirmed that the behaviour is not a defect but, rather, as-designed behaviour in the defined scenario being used for testing and the defect has been resolved with status 'As Designed'.

Please reference this excerpt from pg. 31 of Configuration Guide for reference explaining why the due date is not being reset when the service targets are in the same service target group:

     Tracking time by support teams
     This feature is useful for internal reporting purposes; you can create internal OLAs
     (operational level agreements) to track how long a support team spends on a
     request. When a request is reassigned from one group to another, the OLA can
     keep track of how long each team worked on the request using the contents of a
     field specified in the data source. The goal time is not reset when the request is
     reassigned.

The same behaviour is consistent testing the same scenario with v7.1 through the current v7.6.04 releases. Confirming this is as-designed behaviour explains why this has not been determined to be a defect or problem prior to this time. Additional testing in test systems where the development and testing is taking place also confirms this behaviour persists in for future releases of SLM. The QA test plan includes a test case to verify that reset does not take place within SVT groups.

By definition, service target group functionality logic is one of inheritance.  Following is an excerpt from pg. 38 of the 7.6.03/7.6.04 Configuration Guide noting this design:

     When key criteria for an incident are modified and the incident has a service target
     attached, the system searches to see if a service target meeting that criteria already
     exists in the same group. If so, the new service target attaches to the incident
     request and inherits the data, such as start time, goals, or milestones, from the
     original service target. The system re-calculates the due date and time and the
     original service target is removed.

When the service target group workflow takes precedence, the goal time will not be reset.

As a sidenote, there is another test case to verify that the Reset and Re-Open should not work together. If the service target has both options defined, it is assumed they are not used concurrently.

Because the behavior is consistent with the design of current workflow, there is a decision and choice between tracking across assignment and using a service target group. Either

1) the service target group functionality is implemented (reference Configuration Manual starting on pg. 38) and the due date is not reset with reassignment to a different group and a single service target is attached to the incident; or

2) the reset functionality is implemented, in which case there will be a separate service target attached for each update between Critical and High with separate measurement records for each time either service target attaches to the incident

An RFE has been submitted for evaluation of design change to have both SVT group and Reset functionality co-functional in a future release of SLM: see SW00432818.  As the current behaviour is based on a very mature design model, this RFE will require business impact of current design to be considered.

1. BMC Service Level Management