In defining the default table structure for the service desk operation, we had a few basic goals:

1. To make it easy for end users, or customers, to know where to go to request what they need and to follow up on their requests
2. To make the backend processing and workflows as simple and clear cut as possible for the technical users and approvers who must process the requests
3. To make the system easy for administrators to understand and maintain so that changes may be easily made to one kind of request and how it is processed without affecting everything else

The default setup aims to find a balance between all three of these goals.

We have chosen to segment customer requests into a few distinct request types and tables illustrated in the diagram:

The service catalog offers services to the end user that may be created in one of three tables: Service Requests, Purchase Requests, or Change Requests. Whether or not a particular group of users can request particular services can depend on their group permissions – for instance, our default internal end users cannot directly create a Change Request, while technical users can. An end user may also submit 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 and Change Requests may include a set of tasks that need to be completed before the request can be completed.

The system may be configured so that end users simply create records directly in any of these tables and choose the appropriate service from the service catalog once in the record, or it may be set up to offer users 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.

The separation of requests into these tables makes maintenance and processing simpler than if they were 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, Assets, and other essential components of the system.