I was working with a customer this week who had an interesting scenario - in the System Center 2012 Service Manager Self Service Portal (SSP), they wanted users to be able to raise incidents on behalf of other people. Out of the box, you can pick an affected user in the full Service Manager console, but you cannot pick an affected user in the SSP (it uses who you are logged on as). Therefore, to achieve this via the SSP, we need some other means of taking a user input and populating the affected user field with it. This is a great example of how Orchestrator can add extra desired functionality like this to Service Manager.
This method could easily be adapted for service requests (just use the Service Request Class where I use Incident) and the approach used here to integrate Service Manager and Orchestrator could be used in many other scenarios.
This is how the end result looks in the self service portal (my users are blanked out):
The basic high-level steps to achieve this are:
1) Create an Incident Template
2) Create a Service Offering Category (shows as a 'box' container on the home portal page)
3) Create a Service Offering
4) Create a Request Offering
5) Create a Runbook in Orchestrator which will set the affected user
6) Synchronize the Orchestrator connector to bring in the new Runbook
7) Create a Runbook Automation Activity
8) Add the Runbook Automation Activity to the Incident template created in step 1 above
9) Add the Request Offering to a Published Service Offering
So... Let's begin......
1a) In the Service Manager 2012 console, click on Library>Templates and Create an Incident Template (notice how I create a new MP for this)
1b) Click OK and optionally fill out any additional fields on the incident form. I left all the defaults in my incident and clicked OK.
The next thing you need to figure out is where on the self service portal you would like this Request Offering to Appear.
So lets back up a bit here with some terminology.
A request offering is a catalog item that describes an item, assistance, or action that is available to end users. It also defines information that you want to prompt the users for, which in this case will be the user they are raising the incident on behalf of.
Once you have a request offering set up, you make it part of a service offering, and then service offerings are organized into Service Offering Categories that appear (as boxes) on the self service portal:
2a) In the SC 2012 Service Manager console, navigate to Library>Lists.
2b) Open the Service Offering Categories List and add a category or decide which existing one you will use to categorize the service offering. I created a New Category called 'Raise a Ticket'. The idea is that this will be a place where an end user can go to raise incidents or service requests.
NOTE: You may see more categories in this list than you see represented as 'boxes' on your portal. This is because you will only see a Service Offering Category on the portal once you have created and published a request offering, and made it part of a Published Service Offering within that Service Offering Category. So later on when you have created your request offering, be sure to associate it with the appropriate service offering (and ensure they are published), so that the request offering, service offering, and service offering category all show up on the self-service portal.
3a) In the SC 2012 Service Manager console, navigate to Library>Service Catalog>Service Offerings>All Service Offerings
3b) In the tasks on the right-hand side click 'Create Service Offering'
3c) Give the Service Offering a name. I created a Service Offering called Incidents:
You could alternatively call this tickets / break-fix incidents, whatever your end users will recognise as the correct terminology for what is an incident in Service Manager.
I stored this in the same MP I created earlier that i stored my Incident template in.
3d) Change the Category to the Category added or the one that you chose in step 2b above. I will use the 'Raise a Ticket' category that I created earlier
3e) Follow the dialogs adding values to the fields as required. In the Publish page, change 'Draft' to 'Published'. The other fields are optional but will present additional information in the portal to the user about the service offering:
Here is how my summary page looks:
4) Create a Request Offering (Now is a good time for a cup of coffee or tea, before you start this one :-)
4a) In the Sc 2012 Service Manager console, navigate to Library>Service Catalog>Request Offerings>All Request Offerings
4b) On the right-hand side Click 'Create Request Oferring' and click next on the 'before you begin' screen.
4c) Give the Request Offering a name, and pick out the Incident template that you created earlier in step 1, and then click next
4d) Add the User prompts that you would like to be displayed on the incident form in the portal and click next.
NOTE: When you reach the Map Prompts page of this wizard in a later step, you will map these to properties of the incident class such as title, urgency, impact, description, etc. If there are one or more properties that are not part of the incident class, that you would also like a user to input in this form, and in turn be added to the incident (cost center or Incident Location for example) then you would need to extend the incident class using the SC 2012 Service Manager Authoring Console, and in step 1 create a template based on that class and then use this template in the Request Offering instead. An alternative to this is to use properties of the default incident class that you may not be normally using (such as Alternative Contact Details) and map the output of the prompt to that property when you get to the map prompts page.
The Prompt Type needs to match the Property type that you will ultimately want to map the inputted value to. So for instance with title, this is the Text prompt type, because the property is defined as a String Data Type. And With Category, Impact and Urgency these are defined here as 'MP Enumeration List' prompt types, because the properties I will associate them with (Incident Classification, Impact and Urgency respectively) are defined as List Data Types.
4e) Set the Required Type to Required and Optional as desired. In my case I have made description optional. This is in case the person raising the incident on the portal deems the brief description (which will become the incident title) as sufficient to explain the problem, with no further details required.
NOTE: When creating 'Query Results' prompt types, you will not be able to map Query Prompts to the Properties in the 'map prompts' page of this wizard. The way round this is to use one of these bottom two checkboxes:
This way, the user-inputted values will propagate into the Incident, be visible there, and more importantly be available for orchestration purposes.
So after taking all that into consideration, here is how my user prompts look, and we can move on through the wizard:
4f) In the Configure Prompts page, click the first prompt row and then click the 'Configure' button at the top right of the table
4g) In the 'Select Class' page, select 'Domain User or Group'
4h) in the Criteria page, leave this blank:
NOTE; Leaving this blank will return all Users that have been imported into Service Manager. If desired, the list of users available can be narrowed down using User properties in this dialog.
4i) In the 'Display Columns' page choose the columns that you would like to display, to assist a user in selecting the person they are raising the incident on behalf of. I chose Display Name, First Name and Last Name:
4j) In the Options page of Configure Query Results, check the 'Add User-selected objects to template object as affected configuration items' box and click OK.
It should now look like this:
4k) Configure the other prompt fields as shown below, by clicking the appropriate row and then the 'Configure' button:
Incident Category prompt - choose the Incident Classification Enumeration List
Optionally in the brief description and the detailed description, limit the string length
Urgency prompt - choose the Urgency Enumeration List
Impact prompt - choose the Impact Enumeration List
Once configured it should look something like this
4l) Click next to get to the map prompts screen
4m) On the map prompts page click 'incident' and then the 'Display all Properties' radio button.
4n) Scroll down the list until you see the first property that you need to map, and then select the appropriate mapping:
In my case this is Incident Classification and I choose the entry in the drop-down 'Please select the incident Category: List Item (IncidentClassificationEnum)
In the same way, map the prompts for Impact, Urgency, Title, Description,
NOTE When you map title and description, it will show all string prompts that you created and configured, so be sure to map the appropriate prompt to the appropriate property.
4o) Click Next and optionally add any knowledge articles you may have created that you want to associate with the request offering, and click next
4p) In the Publish page, Change the Offering status to Publish , select an offering owner, and click Next
4q) Click Next in the Publish page and then Create in the Summary Page. Once completed, click Close.
So that's it? Well not quite. Now we have the Incident Template, Request Offering Template, Service Offering and Service Offering category. Next thing we need to look at is creating the runbook and then integrating it.
5) Create a Runbook in Orchestrator which will set the affected user
Now we're going to incorporate the magic of orchestrator to do the cool part of setting our affected user.
So first thing first, lets switch over to Orchestrator.
A few prerequisite Assumptions
5a) In the Orchestrator Runbook Designer, under Runbooks, select the folder you would like to create the runbook in, right click it and choose New Runbook (you may wish to create a new folder by right-clicking 'Runbooks' and choosing 'New Folder').
NOTE: Orchestrator Tips:
When you click on a runbook activity you will see the arrows light up to the left and right of it, which you can connect to preceding or following runbook activities.
When you join an activity to preceding activities, outputs from all the preceding activities are available in connected activities like so:
The following diagram illustrates the contained activities of the runbook, what each one is doing, and the detail of how each activity is configured:
5b) Create the runbook as shown below. These screenshots show the Detail of how each runbook activity is configured:
Runbook Activity 1: Initialize Data - ActivityID
Runbook Activity 2: Get Object - RB Activity ID
Runbook Activity 3: Get Relationship - Related Incident
Runbook Activity 4: Get Object - Incident
Runbook Activity 5: Get Relationship - Get affected user properties
Runbook Activity 6: Set affected User properties
Runbook Activity Link Between Get Relationship - Get Affected User and Create Relationship - Set Affected User
Please see the explanation in the runbook diagram shown above and this link for more detail why you need to configure the link in this way:
5c) Check in the Runbook.
Alright time for the cool integration part. Let's switch back to Service Manager:
6) Synchronize the orchestrator connector to bring in the new runbook
6a) In the SC 2012 Service Manager console, Navigate to Administration>Connectors.
6b) Click to select your Orchestrator connector, and in the tasks on the right, choose 'Synchronize Now'
6c) Refresh until the connector runs, and verifies it completes successfully.
7) Create the Runbook Automation Activity
7a) In the SC 2012 Service Manager console, Navigate to Library> Runbooks, and verify your Runbook appears with a status of Active.
NOTE: If it appears as Inactive / invalid, you may need to close and reopen your service manager console, delete the 'invalid' runbook' and then re-run the connector and it should come in as valid. This can happen if you change the name of the runbook. after it has been synced into Service Manager.
7b) Select the Runbook you created so it is selected, and then in the tasks on the right, click 'Create Runbook Automation Activity Template'
7c) Give it a name, then click OK. I chose 'Antoni Runbook Automation Activity to Set Affected User':
7d) Check the 'Is Ready for Automation' checkbox. Otherwise your activity will not kick off the Orchestrator runbook.
NOTE: Do not miss this 7d step otherwise your runbook will not run!!!!
7e) Click the 'Runbook' tab and ensure that the correct runbook is selcted, and appears in the Name field.
7f) In the Parameter Mapping box, click the Edit Mapping box and choose the Object>Id property, then click close, and click OK to close and save the runbook Automation Activity:
8a) Go to Library>Templates, and Open up the Incident Template, which was the first thing created in this blog post (in my case 'Antoni Incident on behalf of Affected User Template')
8b) In the Template form, click on Activities, click the Add button, and select Runbook Automation Activity, then click ok
8c) Select the Activity template for the Runbook activity you just created (in my case 'Antoni Runbook Automation Activity to Set Affected User' and then click OK.
8d) As this will open the Runbook automation activity, it is worth checking that the 'Is Ready for Automation' Activity box is checked (in the general tab) and also that the correct Runbook is selected (in the runbook tab)
8e) Click OK to save and close the Runbook activity template and then ok to save and close the incident template
OK, you're soooooooooooooooooo close now :-)
9) Add the Request Offering to a Published Service Offering
9a) In the SC 2012 Service Manager console, navigate to Library>Published Service Offerings
9b) Click the Request Offering page, and add in the request offering that you created. In my case this is 'Raise Incident on Behalf of Someone Else'
AND NOW WE'RE DONE!!!!
Test your handy work out by going to the portal, click on your Service Offering, then your Request Offering, then Go to Request Form button in the top right hand side.
SCENARIOS THAT CAN USE A SIMILAR APPROACH
Similar Scenarios you could use some of this method for:
Service Requests - Raising Service Requests on behalf of another person
Adding Users to Groups - Instead of passing in a user to raise an incident on behalf of, pass in a user that needs to be added to groups or manipulated some other way using the Orchestrator Management Pack.
Demo: Automating Service Request Fulfillment from the SCSM Service Catalog with Orchestrator
Demo: Automating Service Request Fulfillment from the SCSM Service Catalog with Orchestrator–Real World Examples
Get an error on Get object "Input string was not in a correct format"
Hi Sam, where and at what point are you seeing that error please?
Between Initialize data and Get Object,looks like it doesnt get the correct ID
I get a warning on Initialize Data.The Activity ID from the "Initialize Data" seem to be different from the "Get Object" Runbook thats where I get the "Input string was not in a correct format"
I also get the below on the runbook incident:
:[4/25/2013 1:40:41 PM]:Parameter values
:[4/25/2013 1:40:42 PM]:Succesfully invoked Runbook Create Incident. The JobId is af57267e-e3a3-47ac-992f-f9567c446107
:[4/25/2013 1:44:01 PM]:Runbook execution failed
This is awesome!
I couldn't figure out how to change the affected user in a SR and this helped me get it sorted out.
Thanks for sharing.
Here's a good question. How can I limit the list of users displayed to users that are in the same OU as the person creating the request?