Having trouble understanding the concept of teams and queues in JSM

Question

Hi there,

Just trying to understand how we are going to work when we move to JSM.  We have Support Engineering Teams in Sydney, Vancouver and LA.  Obviously we will want tickets to route through to those teams queues when a incident or request comes in and needs to be assigned.

I can see all about creating queues, but what I can't seem to find is how to make a queue for a group of people.

I assume in opsgenie we create our support and systems engineering teams.

If our triage team wants to assign a ticket to Support Engineering in LA how do they change the ownership of an incident to that group and then have it appear as an unassigned ticket in a Sup Eng - LA Unassigned Tickets queue.

Would we have a custom field on all the forms that lists 'Assigned Team' which then lists the teams from within Opsgenie and the queues are setup to look at that field to filter the queue information?

We can't use Groups in user management as that is where we have all the groups sync'd from AD for the various permissions globally for Jira and soon to be JSM.

I suppose it loops back to Teams in Opsgenie, can they be referenced on a field on a form in JSM?

If that is the case how do people get limited views of their teams queues?

i.e how can I see my queue and also my teams queue?

Many thanks.

Ste Wright · Answer

Hi @Steven Lees-Smith

Dealt with these as two separate questions!

For team-member alerts...

I'd recommend using Automation - where an If/Else rule would be able to manage this - eg...

* Action: Issue Created
* Condition: If/Else Condition* Sub-Condition: Responder Team = Team A* Action: Send Email to: User A, User B, User C,

* Sub-Condition: Responder Team = Team B* Action: Send Email to: User D, User E, User F

* ...etc

An alternative might be to use Groups - put Users into the Groups, then use Automation to send the Group an email.

I just think the above method requires less Jira Admin involvement - for example, team membership changing, where a Project Admin could manage this instead.

For multi-team approaches...

Is this not something best managed through automation-based notifications (like above) - and queues?

For example, a ticket might...

* Go to a Global Queue first - with key team members notified for reviews
* Get assigned to the Responder Team, who are then notified. Each Responder Team has a queue
* If ticket is escalated to "Urgent" - the Systems Team is notified, and all urgent tickets are in a queue

For user assignment - it does depend on how your team works - but, you could also look at automating this. The Assign Issue automated action has options here for Support teams - such as...

* Balanced Workload: Ensures that each user in the list has the same number of issues assigned.

* Round-Robin: Assigns issues based on the sequence in the list of specified users.

Does this help for your specific scenarios?

Let us know - or if you need any specific help with Automation, we'd be happy to help with further instructions :)

Ste

Steven Lees-Smith · Answer

I am really struggling to understand a multi team structure for support.

A global triage team - they will look at all the tickets.

Then the Support teams at each locations

then the Systems teams at each location where tickets will be escalated to.

Not sure how people achieve a specific team structure with escalations and notifications going to team members when a ticket has been handed to their team.

Steven Lees-Smith · Answer

The list is a pretty stable list of names anyway so creating them manually won't be an issue.

Next challenge, we won't be using the oncall side of things in Opsgenie as we have pagerduty heavily integrated with some of our alerting systems and such.

When the triage team assign a ticket to a 'Responder Team' via the custom field and then the ticket is seen in the particular teams queue, how can we notify members of the team that there is a new ticket in their queue.

I know I am thinking of the ease of ticket ownerships we have now with Cherwell but the concept of just agents all being agents and not easily sitting within a 'Team' is a challenging one that I need to replicate somehow.