Date and Duration Fields on Incidents/Requests

Last modified on 2023/08/03 12:11
Contents

Data calculated based on dates and durations in the life cycle of incidents/requests is stored in the SD_REQUEST and AM_ACTION tables.

Notes

  • Dates and times are stored in UT (Universal Time) format. They are automatically converted and displayed in local time in Service Manager GUI based on the logged-in user's location and time zone.
  • This rule applies to all fields whose name ends with _UT.
  • E_FIELD_NAME external fields must have the _UT suffix.

    example  E_DATE_UT

  • The value of the Display Time property in forms must be True for Date/Time fields.

List of Date and Duration fields by table

SD_REQUEST

Physical name Logical name Definition Notes
CREATION_DATE_UT Creation Date Date on which the record was created in the database
  • Not displayed on Service Manager GUI
  • This date can be used in reports
SUBMIT_DATE_UT Creation Date Date on which the quick call was created for the incident/request
EXPECTED_DATE_UT Expected End Date Expected end date of the incident/request
  • Unused
  • Replaced by the EXPECTED_START_DATE_UT and EXPECTED_END_DATE_UT fields
EXPECTED_START_DATE_UT Expected Start Date Expected start date of the incident/request
  • Specified when the incident/request is first transferred
EXPECTED_END_DATE_UT Expected End Date Expected end date of the incident/request
  • Unspecified in the Service Manager standard configuration
  • Used for customer-specific requirements
  • Usually replaced by the MAX_RESOLUTION_DATE field
MAX_RESOLUTION_DATE_UT SLA Target Latest date on which the incident/request must be solved
  • Calculated by the SLA associated with the category using the CREATION_DATE_UT field
  • Service hours and holidays are taken into account
  • Time on hold is taken into account and the date is automatically shifted
END_DATE_UT Solution Date Closing date of the incident/request
  • End date of the first closing action with a closing status for the incident/request (Completed meta-status)
  • Difference between the END_DATE_UT and CREATION_DATE_UT fields with service hours taken into account
TIME_USED_TO_SOLVE_REQUEST Elapsed Time Time elapsed between the creation date and the solution date of the incident/request
  • Difference between the CREATION_DATE_UT and END_DATE_UT fields
  • Service hours and holidays of the SLA are taken into account
  • Time on hold is taken into account
  • Time expressed in minutes
DELAY Late Time exceeding the SLA target

AM_ACTION

Physical name Logical name Definition Notes
CREATION_DATE_UT Creation Date Date on which the record was created in the database
  • Not displayed in Service Manager GUI
  • This date can be used in reports
EXPECTED_START_DATE_UT Expected Start Date Expected start date of the action
  • Specified when the action is transferred to a group/Support person
START_DATE_UT Date Accounted For Actual start date of the action
  • Specified automatically when Support persons assign the action to themselves via Assign icon.png
MAX_INTERVENTION_DATE_UT OLA Target Latest intervention date for the action
  • Added to the CREATION_DATE_UT field of the OLA defined in the group or in the workflow step
  • Service hours and holidays of the OLA are taken into account
  • Time on hold is not taken into account because it is applicable to incidents/requests and not actions
MAX_RESOLUTION_DATE_UT SLA Target Latest resolution date
  • Unused
  • Replaced by the MAX_INTERVENTION_DATE_UT field
EXPECTED_END_DATE_UT Expected End Date Expected end date of the action
END_DATE_UT Real End Date Actual end date of the action
ELAPSED_TIME Time Spent Time elapsed between the start date and the real end date of the action
  • Difference between the START_DATE_UT and END_DATE_UT fields
  • Time on hold is not taken into account because it is applicable to incidents/requests and not actions
  • Time expressed in minutes
DELAY Late Time exceeding the OLA target
  • Difference between the MAX_INTERVENTION_DATE_UT and END_DATE_UT fields
  • Time on hold is not taken into account because it is applicable to incidents/requests and not actions
  • Service hours are not taken into account To take service hours into account, configure an OLA for the associated workflow step or group
  • Time expressed in minutes
TIME_USED_TO_COMPLETE_ACTION Processing Time Time elapsed between the creation date and the end date of the action
  • Difference between the CREATION_DATE_UT and END_DATE_UT fields
  • Time expressed in minutes

Examples

Quick call for an incident

The quick call of an incident is followed by its transfer to a group, then to a Support person who performs the action.

  • The category in the incident catalog is associated with an SLA of 8 working hours. There are 8 service hours per day (8:00 am to 12:00 pm and 2:00 pm to 6:00 pm from Mondays to Fridays).
  • The incident will be managed by the Incident: Standard workflow containing only one Operation Processing action.
  • No OLA is defined for the workflow.
     
Step SD_REQUEST table AM_ACTION table Notes
1 - Create quick call CREATION_DATE_UT = 27 February - 14:01
  • Action = Quick call
  • ELAPSED_TIME = 05 min
 Quick call duration: 5 minutes
2 - Transfer to a group MAX_RESOLUTION_DATE_UT = 28 February - 14:01 Application of the SLA with service hours taken into account
3 - Processing by a Support person
  • New Operation Processing action for the incident
  • START_DATE_UT = 27 February - 14:10
 Action automatically assigned via Assign icon.png, its start date will be the current date/time
4 - Processing action performed by the Support person
  • MAX_INTERVENTION_DATE_UT = 27 February - 16:10
 There is no OLA
5 - Close the incident
  • END_DATE_UT = 27 February - 18:30
  • TIME_USED_TO_SOLVE_REQUEST = 3 hrs 59 min
  • END_DATE_UT = 27 February - 18:30
  • ELAPSED_TIME = 4 hrs 20 min
  • DELAY = 2 hrs 20 min
  • The Complete Action button in the Action form will use the current date/time
  • Action:
    • Time Spent = Service hours are taken into account
    • Late = Service hours are not taken into account
  • Incident:
    • Elapsed Time = Service hours are taken into account
    • Total Time Spent = 4 hrs 25 min (duration of the Quick call action + duration of Processing action)

Incident placed on hold and resumed

The quick call of an incident is followed by a transfer to a group. One of the Support persons in the group puts the incident on hold while waiting for more information, then performs an action to continue the incident and closes it. Note: The Support person processes the action using the Actions for my Groups menu, without assigning the action.

  • The category in the incident catalog is associated with an SLA of 8 working hours. There are 8 service hours per day (8:00 am to 12:00 pm and 2:00 pm to 6:00 pm from Mondays to Fridays).
  • The incident will be managed by the Incident: Standard workflow containing only one Operation Processing action.
  • No OLA is defined for the workflow.
  • Value of the Other Parameters {SM} Calendar: Default duration of actions (in minutes): 120.
     
Step SD_REQUEST table AM_ACTION table Notes
1 - Create quick call CREATION_DATE_UT = 24 April - 10:15
  • Action = Quick call
  • ELAPSED_TIME = 01 min
 Quick call duration: less than one minute
2 - Transfer to a group MAX_RESOLUTION_DATE_UT = 25 April - 10:17 Application of the SLA with service hours taken into account
3 - Incident placed on hold (pending more information)
  • The Place on Hold / Continue wizard will trigger an action with the current date/time: 24 April - 15:42

   The Scheduled Return date which you can specify in the wizard is for information purposes and is not intended to be the actual resumption date.
4 - Incident resumed MAX_RESOLUTION_DATE_UT = 25 April - 16:02
  • The Place on Hold / Continue wizard will trigger an action with the current date/time: 25 April - 09:27
  • Retrieval Date = Actual date on which the incident was resumed: 25 April - 09:27
  • The SLA target date/time for the incident is calculated again to take time on hold and service hours into account:
    • Difference between time on hold (15 hrs 42 min) and end of service hours (6 pm) ==> + 2 hrs 18 min
    • Difference between start of service hours (8 am) and retrieval time (9:27 am) ==> + 1 hr 27 min
    • Non-working period during service hours (12 pm - 2 pm) ==> + 2 hrs
5 - Close the incident
  • END_DATE_UT = 25 April - 12:14
  • TIME_USED_TO_SOLVE_REQUEST = 5 hrs 58 min
  • DELAY = 0
  • END_DATE_UT = 25 April - 12:14
  • ELAPSED_TIME = 00 min
  • DELAY = 21 hrs 56 min
  • The Complete Action button in the Action form will use the current date/time
  • Action:
    • Time Spent = 0 because no Support person is assigned to the action
    • Late: Time on hold and service hours are not taken into account
  • Incident:
    • Elapsed Time: Service hours are taken into account
    • Late = 0 because the incident's real end date is earlier than the SLA target
    • Total Time Spent = 01 min (only the duration of the Quick call action because no Support person was assigned to the action leading to closure
Tags:
Powered by XWiki © EasyVista 2022