In my last blog post I talked about automating Service Requests with Service Manager 2012, and I also promised to show how to allow end users and other consumers to directly create new Service Requests from a Web Portal. This in indeed a huge step forward to unburden your Service Desk staff. Keep in mind that this procedure can be very complex and needs detailed planning. For a first look I will use a simple example how this can be done. More complex scenarios are planned for later.

****************************************************
The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks
****************************************************

In this example we want that end users can order access to a SharePoint site. Normally this means that the end-user calls the Service Desk and describes his need. A Ticket is created and assigned to a Support Group or an Analyst that will do the work. Now let’s see how this could be done by enabling Self Service for our end users.

Step 1 – Prepare a Service Request Template

I will not go into any details about how Service Request Template are created. You can find this in a previous blog post here –> http://blog.scsmfaq.ch/2011/10/28/news-in-scsm12-beta-2-service-requests/. I will just show you how my Service Request Template looks like.

Take a look at the activities. The first one is a review activity where a person needs to approve the request. As soon as this is done, a manual activity will be activated and assigned to an administrator. Instead of a manual activity this could also be a Runbook Automation Activity that allows the automation of the configuration. If you need more details about that, you can find it here –> http://blog.scsmfaq.ch/2011/10/28/news-in-scsm12-beta-3-automation-of-service-requests/

Now let’s take a look at the activities. At the end these activities must somehow store all information that the user entered in the Web Portal form, so that the approvers and the administrators have all the information they need to fulfill the request. It’s possible that you must customize the default activities and add additional attributes, but in this example we will have a simple approach and don’t need any kind of customization. So all activities are as they come with the product.

Step 2 – Bring your Request to the Service Catalog

Now as the Service Request Template is ready, we want to bring that Request to the Service Catalog.

First we have to create a “Service Offering”. Service Offerings describe an IT Service that consumers can request. Normally a Service Offering contains multiple Offerings for the same Service or area. In this example I will create a Service Offering named “Access Services”. So let’s start by clicking on the appropriate task.

First enter a title, an overview and a description for the new Service Offering. You can also choose a category to group multiple Service Requests together. When you want to add more categories you can do this by configuring the “Service Offering Category” list in the Library.

On the next page you can add SLA and cost information. This is interesting if the requests are billed to the consumers.

Now you can select affected Services. These are Business Services that could exist in the CMDB. In this example, I don’t use it.

The next page allows you to add knowledge articles to the Service Offering. These articles are visible to the consumer on the portal and allows you to publish information about a Service Offering or help information for the consumer.

A Service Offering normally contains one or multiple Request Offerings. Because we did not configure that yet, we will add our Request Offering later.

Th finish the wizard, make sure to set the status of the offering to “Published”. Otherwise it will not be visible on the portal. The “Draft” value allows you to prepare your complete offerings and publish it at a later time.

That’s it, the Service Offering is created. No comes the next part, the “Request Offering” that is based on our Service Request Template. Again, click on the appropriate task.

On the general page enter the needed Information. Then select the Service Request Template you created in Step 1 – the one to order access to a SharePoint site. As you can see it’s also possible to use Incident Template to allow users to submit Incidents.

Now it’s time to define what information you need from the user. Based on this configuration, a form will be dynamically created on the Web Portal. This is pretty cool as you don’t have to worry about creating web forms – this is completely done by Service Manager. Enter the prompts and mark them as required, optional or display only. The data type is very important and powerful. It let’s you capture text, data or bool values, but it also offers you to publish a simple list with values or objects from the CMDB. In this example I will use text for “Justification” and “Simple List” for the SharePoint site.

Depending on the data type you defined for the different prompts you must configure those on the next page. You can configure constraints for the prompts and select the objects that should be displayed for selection (Simple List, CMDB Query, MP Enumeration List). In this example I will not configure anything for the “Justification” prompt but I will add some SharePoint Sites to the “SharePoint Site” prompt.

Unfortunately this list is static. If needed it would be possible to discover SharePoint Sites with SCOM, synch them to the CMDB and then use a CMDB Query prompt to display then for selection – very powerful! But as we are still at the beginning, I use a simple list with static values here.

Now comes a very important part. We have to store the values that the user enters in the form on our Service Request or on the activities in it. This is done by mapping that different prompts (values) to attributes – you MUST map all prompts to a property otherwise you cannot complete the wizard because the entered data would not be saved. I will map the “Justification” prompt to the description of the review activity and the “SharePoint Site” prompt  to the description of the manual activity. Now you may ask: what if I have 20 prompts on the form? To what properties do I have to map all the values? For this you will have to extend the default activities with additional attribute or (even better) create your own activities with the needed properties. I will cover this in a later post.

On the next page you can again add a knowledge article to this specific Request Offering. The article will be displayed for consumers on the portal.

On the last page make sure that you publish the new Offering. Otherwise it will not be accessible from the web portal.

As a last step we have to link our Request Offering with the Service Offering. This can be done by using the appropriate task.

Access to the different offerings is role-based and can be controlled by using so-called “Catalog Groups”. For now, I will test it with an administrator account. Otherwise the blog post gets even longer – and I think it’s already long enough 🙂 So again, this will be covered in a later blog post.

Step 3 – Crete a Service Request (consumer perspective)

Now connect to the portal and check if the new Offering is visible. The process of creating a new Request is straightforward.

Consumers can track their Request directly in the portal. Again this can reduce the number of phone calls in your Service Desk because the end user has all the information he needs in the web portal.

Step 4 – Check if the Request has been created

Now connect to the Service Manager console and check if the Service Request has been created. It seems to be there, cool.

Now check the activities as they should now contain the values (based on the configured mapping) that the user entered in the form.

Everything is there as it should be – the Service Request can now be fulfilled. In this example the activity that does the configuration is a manual activity and must therefore be assigned to a technician that will give the user access to the SharePoint site manually. But you can also use this together with Runbook Activation Activities to completely automate that step. Now I guess you can imagine how powerful this can (and will) be if you have this up and running in your production environment. Now start building your own Offerings!

regards
Marcel