Deciding how to segment the service catalog and what table structure to use for an ITIL implementation can be quite a challenge. The default setup of the service catalog balances the following basic goals:

• Make it easy for end users (the customers) to know where to go to request what they need and to follow up on their requests.
• Make the back-end processing and workflows simple and clear cut for the technical users and approvers who must process the requests.
• Make the system easy for administrators to understand and maintain so that changes can be implemented for one kind of request without affecting how other records are processed.

The Service Catalog offers services to the end user that may be created in one of two tables:  Service Requests or Incidents.  Whether or not a particular group of users can request particular services depends on a few things:

• Their group permissions – for instance, our default internal end users cannot directly create a Change Request, while technical users can. 
• Which SLA Customer group they belong to and which business services and service offerings are included in all SLAs available to that SLA Customer group. 

Internal customers will submit service requests – which can include the purchase of items – or an incident to report a problem or interruption to a business or technical service.   If merited, that incident may lead to the creation of a Problem and a Change Request by technical staff.

Service Requests, Incidents, and Change Requests may include a set of tasks that need to be completed before the request can be completed. Service Requests and Change Requests can also include approval workflows prior to the work being scheduled.

The system can be designed so that end users can either...

• Create records directly in any of these tables and choose the appropriate service from the service catalog once in the record, or 
• Select from a set of hotlinks to create requests for specific services without them needing to know what table will be used to store and process the requests until after they have created them.

Separating requests into distinct tables simplifies maintenance and processing compared to storing them all in a single table, since the fields, form layouts, access permissions, workflows and rules can be specific to the needs of the particular request type.

The orange arrows in the diagram above show the predefined conversion paths a request may easily take, if a technician believes it is appropriate: a service request can, with a click of a button, generate an Incident or a Change Request, or can be linked to existing incidents or changes. Likewise, an Incident can generate or link to an existing Problem, while a Problem can generate or link to a Change Request.

A Problem may be related to multiple Incidents and a Change Request may be related to multiple Problems, Service Requests, and, through Problems, Incidents. Naturally there are relationships within each of these tables to Users, Teams, Configuration Items, and other essential components of the system.

Service Requests vs. Change Requests

For some services, it may be unclear whether they should be offered through a service request or a change request. For instance, account provisioning, employee off-boarding or on-boarding, or simple application changes could go under either category. We like to use the notion that changes that do not require approval may best be handled in the service request table, while those that do require changes or require careful scheduling belong in the change request table. Approvals are available to both Service Requests and Change Requests, so the services can be configured accordingly. 

SLAs are primarily tied to service requests and incidents, with less weight given to SLA targets for change requests, since changes must often be carefully scheduled during maintenance windows.  Thus if you are concerned with measuring turnaround time for standard services, they are generally best handled in service requests.