Service Request Fulfillment and Incident Requests are similar in Service Manager. You may actually be wondering what the difference is between the two. The ITIL and MOM frameworks basically define an incident as a service interruption to an IT system. A service request is a request for service/access to an IT system. This can be requesting access to a system, or requesting a new system to do a task.
Service Requests also have an approval method. This allows for several people or groups to be involved in the process. This can be especially useful for a request that may involve a process where multiple things are done. The system has the ability to lay these steps out and ensure that they are done in the correct order.
Another way service requests are beneficial is that they can be tied to Orchestrator Runbooks. This means that after the service request has been approved, you can have Orchestrator go ahead and do whatever process is needed to fulfill the request. This allows for automation in your environment, freeing up valuable time for your IT staff.
Service Request Template
I would begin service requests with a dedicated template to every service (or like services). These templates will allow you to customize the process for your different services. Putting in the time now to define these different workflows can make automation possible later.
To create your workflow, go the Activities tab of your service request template. Click the “+” button, and select the appropriate activity template. You have five options there. The “Default Dependent Activity” is an activity that the service request relies on to continue. The service request will not continue until this activity is completed. This activity can be automated. The “Default Manual Activity” is the same as the dependent activity, but has to manual. It cannot be automated. The “Default Parallel Activity” is an activity that can occur at the same time as the other activities. This can be helpful if three people of the same approval level need to approve the service request, but in no particular order. The “Default Sequential Activity” is the same as the parallel activity, but the approvals must be done in a set order (such as a manager then director approval).
The “Default Review Activity” is the primary activity. This is the actual approval item. This is why it is important to have different templates for all services. Here is where you specify the actual users that must approve a request.
In the “Approval Condition” box, you can specify whether there has to be complete approval, or a percentage of those on the approval list. You also specify that the activity is automatically approved. Automatic approval can be used if it is a service that everyone gets access to, but you still need a record of the request. Simply fill this out for your organization’s requirements.
Service Offering
Now that we have the template set up, we need to create a service offering that can be published to our customer web portal and the console. Go to the “Service Catalog” option under the Library node of your console. Select the “Request Offerings” tab and “Create new request offering” from the right column. Select the template we created. Create your user prompts. I am creating a service request for network storage access, so I have a field for the requesting user and the directory.
There are a few advanced options you can do here, such as creating a box for the user field that will list all of the users in your environment. That is outside the scope of this article, so I will not go over it here.
For the “Map Prompts” options, be sure to map these fields to existing, default Service Manager fields. This is especially important if you want to do any automation with Orchestrator, as it will not pull custom fields. For my example, I am mapping the username to the title field and the directory to the description field.
Using these two fields will transfer nicely to Orchestrator for automation. Next, follow the remainder of the wizard and publish the offering. Now your users can submit service requests for your services.
Summary
This is a very general article about service requests. Hopefully it can help you to get started with using this feature of Service Manager. It is important to understand the difference between an incident and a service request. Remember that an incident is basically a disruption of a service, while a service request is granting access to existing service or a new service (or system). From a conceptual level, a service request is more like a change request then an incident. It provides a built-in workflow method for you to define and use.
