Question

Ability to Create Separate Ticket Queues for Separate Teams

  • 2 May 2023
  • 4 replies
  • 127 views

Userlevel 1
Badge

Our team has been evaluating whether it’s feasible to incorporate some external departments into iiQ. We regularly have situations where a ticket has been submitted to one department that would be better suited for another, or where one team starts a ticket and then passes it off to another once they’re done what they can. But we’d like there to be, essentially, separate ticket queues for these teams, that an admin could then move if needed.

We tried building some custom policies cloned from the default Agent role one, and creating accounts for external departments. Since we don’t necessarily need everyone looking into other departments’ tickets, we also tried segregating them by location and limiting users’ abilities to view with custom policies. Unfortunately, none of these steps really worked the way we needed. It seems like anyone with the Agent role has the ability to see any ticket, regardless of location, and segregating things by location doesn’t seem to have any effect at blocking users’ abilities to see tickets.

It seems like this is a combination of lack of custom roles, and multiple policies being applied at the same time inconsistently.

For districts with multiple schools and multiple IT teams assigned to those schools, it seems pretty reasonable that admins would want to segregate tickets and keep teams working on their own tickets. Our situation is very similar in that regard. Unfortunately, it doesn’t seem like iiQ has the capability to handle this use case yet. Is this something on iiQ’s roadmap?


4 replies

Userlevel 5
Badge +12

For our district, any non-IT departments that work tickets, we gave them a policy with basically only Login access (no location-based permissions at all) but we have our Site Option set to only allow view/work/resolve tickets if it’s assigned to the agent or a team they are a member of. Otherwise, they can’t do anything with them.

 

The downside to this setup: 

  • If they accidentally assign to the wrong agent or team - they have to contact IT to have us reassign it properly.
  • Also, we have folks who shouldn’t really be “Agents” but need access to assets, so we made them Agents. Now we have over 500 agents in the system because of asset permissions, and all of them populate as being able to assign a ticket to.

It’s our understanding that there’s change coming to permissions fix some of this. There’s also a lot of ideas related to this that you can vote on to get the devs attention 😉

 

It’s not the greatest setup that we have, but it was the best thing we could come up with for now until we see the permissions overhaul. In fact, if you have location-based IT teams, this could possibly work better for you than it does for us.

 

An ideal permissions setup for us would be to require a team assignment, and then narrow down the agent picklist to members of that team to prevent overstepping, unnecessary view permissions, and mistakes in assignments, etc. Unfortunately, that doesn’t exist today.

 

 

Userlevel 7
Badge +14

@KNorquist 80303f1 mva - this is on our roadmap. 

As @jclark16 mentioned we are doing an overhaul of our permissions. This is a big undertaking since permissions controls and touches every part of our platform. But we are actively working on this. Please keep a look out for our product updates for when the new permissions has launched. 😁 

Badge

We are trying to spin up a Student Help Desk at one of our schools and would like the Student Help Desk Supervisor to be able to use the ticketing system. With the current options for permissions, we really have no way from preventing access to the general queue of tickets for this user. I’m hoping for permissions changes mentioned in this thread to be implemented so that we can create a separate Student Help Desk queue for tickets based on team assignment. 

Userlevel 7
Badge +12

@DMurphy 120e383 slrsd Love this idea! Hopefully, this is something we will be able to produce in permissions v2! 

Reply