Differences between Incident, Problem, Change, Release, and Service Request

This article first gives an overview of the ITIL definitions of these different classification of items, provides sample use cases, and provides additional notes regarding how these classifications manifest themselves within TeamDynamix.

ITIL Classification Definitions

An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted one or more Services is also an Incident. For example: Failure of one disk from a mirror set.
A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.
The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.
A collection of hardware/software documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.​
Service Request
A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

Use Cases

A good simple use case for most of these would be that there are fifty Incidents of WiFi being interrupted. Those Incidents are then rolled up into a single Problem ticket about the lack of suitable WiFi infrastructure. A Change ticket could then be opened and the WiFi infrastructure is then changed/upgraded to be more resilient and reliable. A Release ticket could then be created and then the institution could then release new documentation and justification for the upgrade in WiFi infrastructure. Also, release the news that the new WiFi infrastructure should be more consistent, and that people should not worry, etc.

Use in TeamDynamix

As these definitions may not exactly suit a specific organization's processes, these various classifications can be renamed and turned on/off as necessary.

Please note that as of 9.1, Service Requests are items that have been associated with a ticketing workflow, and these items must be promoted to one of the 4 main classifications seen above. However, 9.2 sees Service Requests be made its own separate classification that can be created and used independently of a workflow.

The hierarchy of what can be used as parent/child tickets in TeamDynamix is as follows:

Incident Service Request*

* Service Requests can only be included in the hierarchy in versions 9.2 and up.

Note that a parent ticket can contain any of the child classifications below it. This means that a Release can contain any Problems, for example, without a Change between them in the hierarchy.

When a parent ticket, such as a Release, is updated, a technician can elect to update/close all the child tickets, such as Changes, Problems, and Incidents. that are nestled within it.

When a ticket is converted to a project task, any existing parent linkage is removed, but children tickets will remain. However, updates made to the ticket based on the corresponding project task's status will not be cascaded to its children.


From article published in TD Community https://solutions.teamdynamix.com/TDClient/KB/ArticleDet?ID=2568 
Print Article


Article ID: 38856
Fri 9/8/17 1:40 PM
Thu 4/25/24 8:35 AM