Is there is a way to configure Team Management using Hierarchy?

Muhammad Abtahaj

Is there is a way to configure Team Management using Hierarchy in Jira Service Management ITSM projects?

I need a solution for my organization in which there are multiple roles. And each roles are responsible for specific items. Example of hierarchy I want are shown below:

1 - HOD 

1.1 - Lead support Coordinator

1.1.1 - Support Coordinator

Note that each hierarchy have some users.

I want this as dynamic and easy to change to avoid hassle in configuration.

Moving further I want this hierarchy in assigning my tickets, Setting up escalation matrices. Generation of reports and also in dashboards as I want tree type structured summary. 

Also kindly suggest if there is any addons from marketplace for this feature.

 

Mark Segall

Hi @Muhammad Abtahaj and welcome to the community!

I need a solution for my organization in which there are multiple roles. And each roles are responsible for specific items. Example of hierarchy I want are shown below:

Can you please elaborate on the need here?  Specifically, are you looking for:

1. Managing visibility (e.g. 1.1 cannot view issues assigned to 1)
   1. In this case, you'd want to look into Issue Level Security
2. A mechanism for identifying which queue the issue should fall in.
   1. You could use components for each tier.  This can be automatically set with automation (more below) based upon your escalation criteria

Moving further I want this hierarchy in assigning my tickets, Setting up escalation matrices. Generation of reports and also in dashboards as I want tree type structured summary. 

Using components as described above will make this easy to maintain and automate.  

Components

Create components for each desired tier (e.g. 1, 1.1, 1.2, 1.1.1, 1.1.2, 1.2.1, etc.).  This will serve as the foundation for everything below.

Bonus - By leveraging components, you could choose to have a default assignee for each tier.

Queues

Create a queue for each of your desired levels.  The queue JQL would look something like this:

component IN (1)

----

That's about it for the basics.  Users could manually change the component or you can take it a step further and let automation dynamically change it based upon business logic (e.g. Issue has been sitting in 1.1.1 for x days, change the component to 1.1 and send notification)

Quick caveats:

• Components are designed so that an issue can have multiple assigned so you'd have a little bit of training
• You'd probably want some type of validation to ensure the field can never be cleared out