Video Screencast Help

Service Desk 7: Assigning Initial Permissions for Incidents Based on Location

Created: 01 Jun 2010 | 8 comments
Language Translations
jmecham's picture
+2 2 Votes
Login to vote

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:

  • Primary
  • CreateIncidentSimple
  • CreateIncidentFromID
  • Main Incident Work
  • CreateIncidentAdvanced

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.

Within each embedded component, change the name of the Support I, Support II and Service Manager components to match with the Location's group names. (ie. “Get Group East Coast Support I)

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.

Final Comments
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.

Comments 8 CommentsJump to latest comment

naresh.gokara's picture

Hi jmecham,

I have configured my service desk in the same way you explained above... but I am able to escalated the incidents upto Support II groups only... If we open and escalate the Incidents(Auto Escalate)... its not getting escalated to Service managers group.. Below I have explained the scenario in detail..:

- I have created the customer groups for 3 levels.. Support I(Location SG I), Support II(Location SG II) and Service Managers(Location SMs)
- I have edited the Routing Rules workflow to route all the incidents of a particular location to the custom Support Groups.
- I have modified the Incident management workflow as you explained above...

but still after doing all these.. I am able to escalate the incidents up to Support II Groups only, I am opening an incident escalated to support Group II and selecting the auto escalate option.. but this incident is not getting escalated to Service Managers Group..

Do i need to configure some thing else to make this work..??? Please Suggest..

Thanks in Advance..

Naresh Gokara. 

Login to vote
jmecham's picture

By default auto escalation goes to the Support II group.  Are you wanting autoescalation to go straight to the Service Managers and skip support II?  Or do you want it to autoescalate to the servicemanagers if it is already assigned to Support II?

The Autoescalation is handled in the routing rules project in the Determine Escalation model.

Login to vote
naresh.gokara's picture


I want to auto escalate the incidents to service Managers(Custom Groups) from Support Groups II(Custom Groups)..... in the Routing rules project I can determine the escalation to only support Group II.. but I couldn't find any option to configure further escalations to any custom groups or service managers. 

Can we define more escalation levels in the Routing rules Project..??



Login to vote
jmecham's picture

I think it is possible.  You would probably need to use a matches rule based on assignment and then route accordingly. 

Login to vote
naresh.gokara's picture

There is only 1 Determine Escalation model in the Routing Rules Project... and I have configured this model in such a way that using a matches rule all the incidents which belongs to a particular location will get escalated to respective Custom Groups(Support II).. but where can i configure the 2nd Level of escalation... i.e. Service Managers(Custom Groups). We are also looking for the 3th level of escalation to the custom groups created in Service desk.

Where exactly i should do this..???

Login to vote
jmecham's picture

Once you get to a certain level you can enable regular escalation rather than automatic escalation.  This will allow the workers to route the ticket to whatever group they want rather than the workflow choosing for them.  Will that work for you?

If you want every group to use auto escalation then you would need to edit the workflow to check first which group the ticket is assigned to and then route it to the next group up.

Login to vote
naresh.gokara's picture

Hi Jmecham,

I want the auto escalation for all the groups/Levels.... I have tried modifying the Routing Rules Worklow, but I couldn't define more than 1 escalation in the Determine Escalation Model... Do I need to setup this escalation in some other workflow?? or am I missing some thing in this process???

Can you give me the detailed process like how to configure the 2 Level escalation and in which workflow...?


Login to vote
Subhaneel's picture

I have followed the guidelines, in order to create custom groups, adding them to application properties, and modifying the 
Routing Rules workflow. Now my tickets are getting routed properly to the custom groups. But bizzarely, these groups do not have the 'Can Edit' Permission enabled for these tickets. I had copied the permissions from Support II, and have checked and rechecked, that the permissions are same as Support II. But still for these tickets, even though they are assigned to my new group Support III, Support III does not have edit rights, whereas Support II has it, on these very same tickets.

Am I doing something wrong? Please advise.


Login to vote