The Services table is the source for the support operation's Service Catalog. It holds a record for each service that may be offered to end users through the service catalog. All services offered by the organization to end users should be managed here and this table's workflow is used to manage the approval process for a new service. Each service is offered through a different request type, such as a Service Request, Purchase Request, or Change Request. Each service is therefore associated with one of these three tables, and this association is defined in the Services field called Show in Table.

Use Case

There are two ways to request a particular service: one is to create a new request of the correct type, such as a Service Request, and then to pick the service category and then the service from the drop-down list of services. The second method is to use an internal hotlink such as "Request a Password Reset" which will take the user to a new record in the appropriate table with the Service automatically set to password reset.

The Standard System Demo contains some sample services. Naturally, your organization will want to create its own services, delete some of our sample services, or change the associations we have made for those services. For instance, the onboarding of new employees is currently managed through the Service Request table under the Service Category New Employee Setup. Some organizations may prefer to manage new employee setup through the Change Request table instead. Making this kind of change is a matter of modifying the service record and changing the field called "Show in Table" to point to the desired table.

Since the Service Catalog is the backbone for many support operations, the Services table has several special fields that are pulled into the corresponding request to enable automation, escalation, and special field visibilities and dependencies based on the type of service.

Note that in an effort to allow simplicity, we have not added a table to hold different SLAs, but instead have added simple SLA fields to the Services table. For organizations with a variety of complex SLAs based on multi-field criteria, it will make sense to create a separate table to manage all SLAs and then to pull in the appropriate SLA record for a particular service.

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 offboarding or onboarding, or simple application changes could theoretically go under either category.

The system is constructed on the principle that service requests do not require approvals. They include only "pre-approved" services. Change requests may have approval workflows and complex approval processes. So if you do not require approvals for employee offboarding or simple application changes, they may be best handled as service requests, while if you require approvals for employee onboarding, it may make sense to put that service in the change request category.

Of course, it is also possible to build out approvals for service requests if needed, but we like to use the approval question to help distinguish where a particular service should go.

Approvals and Tasks Related to Services

Some services may have associated approval workflows or standard tasks or task workflows. These options are available from the additional tabs in the Service record:

In the current version of the ITIL template, approvals are available out of the box only for Change Requests. Tasks are available for both Service Requests and Change Requests.

Approvals for Change Requests

There are three options for how to handle approvals for a change request, shown in the Approval Generation Method drop-down below: using a predefined approval workflow, manually created ad hoc approvals, or both:

For a Predefined Workflow Only, users will select from existing approval workflows related to change requests. If none yet exist, they can use the button to create a new approval workflow on the fly.

If they select Manually Created in Request Only then no further information is needed in the service record, and the users will be able to add the approvals manually within the individual change request.

Approval View in the Change Request

The selections made in the Service will result in different options appearing within the Change Request.

In a Change Request based on a predefined workflow only, the user will see the workflow listed and a button to generate the approval records. If the user has permission to edit the Approval Workflow Title field, then it will also be able to select a different workflow as needed:

If both predefined and manual approval creation are permitted, the user will see an additional checkbox, Create Approvals, that can be expanded to add one or more ad hoc approvals.

If only the manual approval creation is defined, then the user will just see the option to Create Approvals and will add any approvals needed.

Note that if the Approval Required field in the service has a Yes value, at least one approval will need to be created and approved to move the change request forward to completion.

Tasks for Change Requests

The Tasks tab of the service allows the selection of a method for task generation. The available methods depend on the request type and they are different for service requests and change requests. Change Requests have two options for the task generation method: Predefined Task Workflow and CR Single Task from Template.

Change requests are typically associated with one or more assets. Task handling for change requests is therefore designed to create a task for each asset that has been associated with the request. If the user chooses 100 assets for a change request and generates tasks, whichever tasks are defined for the change request are created 100 times, one for each asset. The tasks are generated in this way by using a task template and pushing its details down through the asset records, so this necessitates restricting some of the other task generation options.

Predefined Task Workflow allows the selection and/or creation of a Task Workflow with predefined task templates arranged in a sequential or parallel order (see more details about configuring task workflows in the Task Workflows section).

Note that if your workflow has 3 tasks, they will each be generated for each asset.

The CR Single Task from Template option is more common for change requests involving numerous assets. Here you define a single task template to be used with the change request.

Note that a single task may have several predefined steps, presented as a checklist, to assist technicians in performing the task. See the sections on Task Templates and Task Steps below for more details on how to set this up. Below is an example of a task template that has been defined with specific steps:

Using task steps within a single task makes sense for a change request.

While setting up the service, if the task template you want to use does not yet exist, the Create and Apply New Task Template button can be used to bring up the task template screen to define a new template, and once saved, that template will be selected for the service you launched it from.

In the actual change request, it is possible when using this task method to select more than this one task template to generate. Once having generated the default task, the user may select from other pre-defined tasks and generate them as well.

Tasks for Service Requests

For service requests, there are some different task generation options. There are three possible methods:

Predefined Task Workflow has the same usage as it does in change requests, except that the tasks are not tied to assets and are just created once per request.

With this choice in a service request's service, another field - Enable Ad Hoc Tasks – appears, and if it has a Yes value, then in addition to the predefined tasks, the user may create additional tasks for a particular request.

User Selected Tasks allows the service manager to create a set of possible tasks that will be displayed in a service request as checkbox items, so the user may select which tasks are relevant for this particular service request and generate just those tasks:

The Create Task Template button is used to create the potential tasks as templates. Ad hoc tasks may also be enabled for this type by selecting Yes for the Enable Ad Hoc Tasks? field shown above.

The user checks the boxes for the desired tasks, then clicks Generate Task(s) to create the individual task records. These tasks, since they are all optional, are defined as parallel tasks without specific prerequisites.

User Generated Ad Hoc Tasks – this selection allows the user to create manual tasks in the service request without reference to any preexisting templates. In this case, the user will see a button in the service request to create a new task:

When creating an ad hoc task, you can make it sequential by selecting one or more prerequisite tasks.

Service Catalog Management

Note: Because the Services table has some special fields, several of them have onscreen explanations. These explanations are accessed in the input form by clicking on the underlined field labels.

Once the Service Catalog is initially set up by creating the appropriate services in the Service table, new service items will be created by staff members only when a new service is planned or initiated. Existing services may naturally be modified as needed. Initial permissions are set so only users in the admin, Service Manager, and Change Manager groups can create/modify/delete services.

Service records may be created in a state of Planned or Active. Once all active services have been set up during the initial system configuration, it may be desirable to edit the workflow to deselect the Creatable box for the Active State, so that future services must start in a status of Planned and go through an approval process. Temporarily inactive services should be placed in the Inactive state. Services no longer in use can be placed in the Retired state for record keeping.

Workflow

Saved Searches

Some of the default saved searches provided are detailed below.

Ownership

Services are owned by the person who creates the service. Specifically, a Service record is owned by the user whose Login matches the Creator Login field.