Service Desk 7: Assigning Initial Permissions for Incidents Based on Location
Description of our environment
We have more than one location supported on the same helpdesk. Each location has their own Level I, Level II and Level III support groups. By default, Service Desk will route all new incidents to the Support I group. The routing rules can be edited in SD.RoutingRules to route based on location as seen in this video that nmithelmore made available. This routes the ticket to the desired group, but all of the same permissions are still set for the Support I, Support II and Service Managers groups. In our environment we need both the routing and the permissions to be based on Location.
How to set permissions when a ticket is created
Step 1: Create Groups
Using either an active directory import or manually, create the tiered support groups you plan to use for each location. I will use a simple example of an organization that has operations on the West Coast and the East Coast. In our organization, location is not geographic but different business units within the same geographic area. I will use the East Coast West Coast example to make it more clear. In our case I also copied the permissions for these new groups from the existing Support I, Support II and Service Manager Groups when I created them.
Groups created for this example:
East Coast Level I
East Coast Level II
East Cost Service Managers
West Coast Level I
West Coast Level II
West Coast Service Managers
Step 2: OpenSD.IncidentManagement project
When opening an existing workflow like this be sure to use a versioning system. When opening the project, you will be prompted for a name. By default it will be SD.IncidentManagement and in our case I add 2_0 to the end so I know this is not the default workflow.
Step 3: Familiarize yourself with the workflow
There are 5 main models in this workflow with many other contained inside of them. The 4 main models are:
- Main Incident Work
Within the Primary model is the “Incident Management Process” and you will notice a component called "Setup Process". This is an embedded model that handles the group permissions which we will be editing.
The models "CreateIncidentSimple" and "CreateIncidentFromID" both reference the "Primary" model within their workflows and will not need the same changes made in Primary. "CreateIncidentAdvanced" however, does not reference the Primary model and has it’s own “Setup Process” component that would need to be edited in a similar way. This example will only go through the process of editing the Primary model.
Step 4: Familiarize yourself with the Setup Process Component
Go back to the Primary model and double click on the Setup Process component to view the workflow within it. Along the left side are several “GetGroupByName” components; each one corresponding to each of the support groups.
Step 5: Sort based on location
In the left pane search for “Matches Rule” and drag it onto the workflow. Edit the component and in the “Compare To List” add the locations of the different support groups. In this example I added East Coast and West Coast (note: These values need to be entered exactly like they are in the location field for the users). Set “Compare To Variable” to “LocationAffected.Name”.
Step 6: Add embedded component models for each of your locations
Search for “Embedded Component Model” and drag as many onto the workflow as you need for each location and name them appropriately with the corresponding location (i.e. East Coast).
Step 7: Copy default process
Within each embedded component added above, paste the default process from “GetGroupByName – Support I” (Component number 5) to “Add Process Permisions” (Component number 16) and connect the start and end components.
Note: In this example, I did not edit the “GetGroupByName – All Users” or “GetPermissionByName –CanView All Incidents” components. That portion of the workflow might not need to be inside of these embedded components but I have not tested that.
Step 8: Edit Each Get Group Component
Open each GetGroupByName Component that you renamed above and edit the name parameter by clicking on the ellipses button on the right.
Change the “Value Source” to “Constant Value” and enter the corresponding service group exactly as you named it in Step 1 above.
Step 9: Make Connections
After creating and editing each of the Embedded Models for each location, create a connection going from the “Matches Rule” Component to the corresponding embedded model. Then connect each embedded model to the “End” component.
Delete the connection between “Setup Process With Specified Process View Page” and the “GetGroupByName - Support I” component. Create a link from “Setup Process With Specified Process View Page” to the “Matches Rule” component.
From the “no match” option on the “Matches Rule” component, create a link to the “GetGroupByName – Support I” component.
I recommend trying this out in a test environment in your area before putting it into production. If you don’t do it correctly you could end up with tickets that have no permissions set for them. Also, some of the escalation and other processes will also need to be edited to fit your organizations needs. I have not gotten that far yet but when I do I will make another post.