Require team membership for ticket assignment?

In addition to this, we would want the person resolving the ticket to be required take ownership of the ticket first. Currently our agents can resolve tickets while it’s still assigned to another agent.

I’m not sure I follow what you are asking.  Have you tried looking at the rules you can setup where tickets are automatically assigned to a person, or a team?  I do not think you can disable the ability to change the assignee on any ticket but you can definitely write a rule where certain tickets are assigned to a person, or assigned to a team.  

Sorry, I know I didn’t explain it the best. I’ll give it another shot lol.

If I assign a ticket to a team, I would only want agents who are members of that team to be able to take ownership/work that ticket. As it stands today, I can assign a ticket to a team, but any other agent can still work that ticket if they choose to. So it almost defeats the purpose (for us) to have teams, since it’s nothing more than a label at that point.

The other issue I see too is that it doesn’t matter what agent the ticket is assigned to, any other agent can resolve the ticket. For our scenario, we’d want them to be the owner of the ticket in order to resolve it. Otherwise it becomes kind of a “wild west” situation.

Ahhh I see now!  I know in your permissions you can alter whether people can “change agent”.  If you adjust their permissions they won’t be able to change the agent at least. But I do not think you can lock it down where only the agent can comment, and only that agent can resolve.  

But I think you can write some rules.  Maybe “when ticket is created for a certain location or for certain issues/categories, assign to the team”, then maybe a rule when ticket is updated and then play with “when field is updated-assigned team” or the team conditions.  And then you can have it reassign it to the right team or send you an email.  Have you played with rules much?  They can be fun but a time consuming sometimes to get exactly what you want.  I usually start with one rule, then create a ticket and test it out.  But I let others know I’m doing it because whatever rule I create can affect tickets coming through now and I don’t want that to always happen-or I do it after hours where tickets are not really generated as much.

This rule works where if a ticket comes in by someone from our location, it automatically gets assigned to team SOUTH.  I took the ticket as I’m on the SOUTH team, but then had someone else try to put the ticket in their name and change the team to a different team.  This rule forced it back to team SOUTH and put the ticket in my name.  This just changes that portion of the ticket though and doesn’t prohibit anyone else from commenting, or jumping into my ticket or resolving it.  You can also have it set to email you that someone updated the ticket too that isn’t on your team. 

You can create a rule maybe that is for when tickets are resolved, that says “when resolved by other agents, send email to you” or something like that. Not sure if this helps.

I changed the permissions of my agents to only be able to work tickets at certain locations. They can view the ticket but they cannot change anything on it or assign it to themselves. It appears as “read only” I have to do this one by one. I have over 50 agents so it is a pain staking process. I hope that this helps. 

I guess my question would be if the ticket it assigned to a team and others cannot work the ticket how would you go about transferring the ticket outside of the team if the request was put in wrong or it belonged to a different team and need reassigned. I would think in your scenario you would only be able to see agents who are part of the team for transferring. If that makes any since. 

As far as other agents working tickets, if I am an agent and the ticket is assigned to someone else. If I start the ticket or resolve it, I am now the owner of the ticket. I am not sure if any of this helps. 

@nburke I considered using rules, but as you mentioned it doesn’t cover everything. And I am trying to avoid getting into rules overlapping. Honestly, there’s an idea post floating around asking for more granular permissions that this would fall into - if we could limit some of those view/assign/work/etc ticket permissions to teams rather than locations, would likely solve this. I’ll have to throw some comments on it and try to get the iiQ devs attention lol.

@Cecilia-DCSS we feel your pain - we’re a pretty large district and we have over 100 employees in IT alone, all of which are agents who would need to support the entire district. In our case we wouldn’t want to limit any of them to specific locations. Our previous system allowed us to use teams, kind of like a group of SME’s. So if you wanted to work the ticket, you had to be a member of that team, or you had to reassign it to a team you were a member of before you could work it. It just made the metrics make more sense later.

@cris.ward for that scenario, it would be up to the agents in that team to verify the issue is correct, and if not they would reassign it to the appropriate team. We try to encourage people to stick to their assigned teams when working tickets, as to not step on any toes. We’ve already had scenarios where someone had ownership of a ticket and had already performed some work on it. A second person took over the remainder of the work, but did not reassign it to themselves and they weren’t part of the team the ticket was assigned to, but it let them resolve the ticket without the ownership being updated at all. It just creates metrics complexity when those things don’t line up the way we intend.

All that said - I am loving the feedback, it’s giving me some new perspectives! Thank you all for the comments thus far :)

Agreed, rules can sometimes make things more complicated than they need to be.  Hopefully something comes of this for you!

@jclark16 and @nburke Love seeing your collaboration here!