Should I use Orgs or Queues?
Morning all
Looking for some opinions from those experienced in running multiple 'desks' within the Service Desk. Here's the sitch;
We have 4 functions to cover; IT Support, a subset of IT support which handles primarily Cargo Support, CLC (a non-IT user department supporting airline-provided systems), and the (one-man-band) support in our Amsterdam office.
At the moment, they have
(main) IT Support - queue on the KACE
(cargo) IT support - use the same queue with different categories
CLC - a different and obselete helpdesk
AMS - none, badgered to death :)
I'd like to have them all on KACE, but be able to seperate them sufficiently that all have their own queues (although with the option of moving tickets from queue to queue!) and ideally granular security roles so I can keep CLC off my IT tickets (for example). All four will have different categories and probably need different ticket rules.
Queues can do some of these things, and Orgs can do others, but I don't really have a feel of which would do it better. Anyone like to share their experiences? I'd be grateful :)
Looking for some opinions from those experienced in running multiple 'desks' within the Service Desk. Here's the sitch;
We have 4 functions to cover; IT Support, a subset of IT support which handles primarily Cargo Support, CLC (a non-IT user department supporting airline-provided systems), and the (one-man-band) support in our Amsterdam office.
At the moment, they have
(main) IT Support - queue on the KACE
(cargo) IT support - use the same queue with different categories
CLC - a different and obselete helpdesk
AMS - none, badgered to death :)
I'd like to have them all on KACE, but be able to seperate them sufficiently that all have their own queues (although with the option of moving tickets from queue to queue!) and ideally granular security roles so I can keep CLC off my IT tickets (for example). All four will have different categories and probably need different ticket rules.
Queues can do some of these things, and Orgs can do others, but I don't really have a feel of which would do it better. Anyone like to share their experiences? I'd be grateful :)
1 Comment
[ + ] Show comment
-
Orgs will create separate DB and if your requirement is to pass ticket from one queue to another queue then all the queue should be part of same ORGS you can't pass ticket from one ORGS queue to another ORGS Queue. - Deepak Gupta 9 years ago
Answers (26)
Please log in to answer
Posted by:
airwolf
12 years ago
Well, you're limited when it comes to permissions for something like machine/software inventory. It's all or nothing, so if you want separate management of inventory and/or assets, you'll have to use multiple ORGs.
Queues have three permissions: submitter, approver, and owner. If someone is an owner in a queue, you cannot restrict them to specific categories or tickets - they have full access to the entire queue. It sounds like you just want to limit people to ownership in specific queues - and you can definitely do that. We have something like 12 queues, and our users can only submit to one, and most of our IT staff can only see/modify one.
Queues have three permissions: submitter, approver, and owner. If someone is an owner in a queue, you cannot restrict them to specific categories or tickets - they have full access to the entire queue. It sounds like you just want to limit people to ownership in specific queues - and you can definitely do that. We have something like 12 queues, and our users can only submit to one, and most of our IT staff can only see/modify one.
Posted by:
dfeldman
12 years ago
I'm a new KACE Appliance admin so I apologize if I'm out of line here. I was wondering if anyone received a response from KACE concerning restricting visibility to queues based on being a Ticket Owner. I just spoke to support who indicated that even with the 5.4 upgrade, this is not possible. I'm trying to give Owners the ability to see all tickets in only their queue not just their tickets.
Posted by:
airwolf
12 years ago
You want to use multiple queues in the same ORG. In separate ORGs you would have completely separate databases (e.g. different machine inventories to link to tickets, different queues to move tickets between, etc.).
EDIT: I realize I wasn't very clear on this, but there is nothing you described that isn't possible with multiple queues in the same ORG.
EDIT: I realize I wasn't very clear on this, but there is nothing you described that isn't possible with multiple queues in the same ORG.
Posted by:
Acedashdog
12 years ago
Thanks Andy!
There are a few more considerations, which I left off as the description seemed to be getting terribly long. Amsterdam have their own AD and PCs, which I'd prefer not to have bunched with mine for scripting and so on, which is why I thought of Orgs; I guess I could smart-label them on login domain though?
More to the point I want to be able to control the ability of the users in the secondary queues to edit tickets outside those queues. In other words, have a "All CLC Ticket Owners" and an "All Cargo Ticket Owners" label able to edit just their own queue's tickets but NOT tickets in the main queue. Can this be done with Queues? I had a try but couldn't work out a way.
Cheers!
There are a few more considerations, which I left off as the description seemed to be getting terribly long. Amsterdam have their own AD and PCs, which I'd prefer not to have bunched with mine for scripting and so on, which is why I thought of Orgs; I guess I could smart-label them on login domain though?
More to the point I want to be able to control the ability of the users in the secondary queues to edit tickets outside those queues. In other words, have a "All CLC Ticket Owners" and an "All Cargo Ticket Owners" label able to edit just their own queue's tickets but NOT tickets in the main queue. Can this be done with Queues? I had a try but couldn't work out a way.
Cheers!
Posted by:
Acedashdog
12 years ago
Mmmn, queues sound like the answer then. I only want to restrict people to one queue or another, not granularly within them, so that's OK. In point of fact, Amsterdam have only asked for Service Desk so far, so at the moment they don't need inventory (classic "what can we have for free").
All in all, it does look like queues are the way to go. Comforting, because if I make a pig's ear the first time I can dump the queue and go back :)
Cheers Andy. On the nail as ever!
All in all, it does look like queues are the way to go. Comforting, because if I make a pig's ear the first time I can dump the queue and go back :)
Cheers Andy. On the nail as ever!
Posted by:
Acedashdog
12 years ago
Mmmn
After some tests...
UserA has label All Ticket Owners, which is set on the primary queue as "Ticket Owners By Label"
UserB has (just) label All TestQ Ticket Owners, which is set on the test queue as "Ticket Owners By Label"
UserA can create a ticket in the Test Queue, then UserB can edit it, save it, then edit again and move it to the main queue
UserB can then go to the main queue, edit the ticket and save it again.
I'd have expected UserB to not be able to see the contents of Main Queue much less edit them. This was what happened when I tried this before. Or have I missed something?
Sorry if I'm being dense
After some tests...
UserA has label All Ticket Owners, which is set on the primary queue as "Ticket Owners By Label"
UserB has (just) label All TestQ Ticket Owners, which is set on the test queue as "Ticket Owners By Label"
UserA can create a ticket in the Test Queue, then UserB can edit it, save it, then edit again and move it to the main queue
UserB can then go to the main queue, edit the ticket and save it again.
I'd have expected UserB to not be able to see the contents of Main Queue much less edit them. This was what happened when I tried this before. Or have I missed something?
Sorry if I'm being dense
Posted by:
airwolf
12 years ago
If UserB is not a submitter, approver, or owner in the primary queue, they should not be able to even see that it exists. If UserB is a submitter in the primary queue, they can create tickets but only see/edit their own submitted tickets.
Posted by:
Acedashdog
12 years ago
Ah. So if I have "Allow all users as submitters" that would perhaps be the problem?
Posted by:
airwolf
12 years ago
That means anyone can submit a ticket. And they can see/edit any user editable fields in tickets they have submitted.
Posted by:
Acedashdog
12 years ago
Ah, right, got that. If all users can be submitters, all users can create tickets. Duh.
But what I have here is UserB who is a Ticket Owner on the Test Queue, who can switch to the Main Queue of which he is NOT a Ticket Owner, list all the tickets and edit any of them....?
He should only be able to edit ones he himself has created shouldn't he?
But what I have here is UserB who is a Ticket Owner on the Test Queue, who can switch to the Main Queue of which he is NOT a Ticket Owner, list all the tickets and edit any of them....?
He should only be able to edit ones he himself has created shouldn't he?
Posted by:
nshah
12 years ago
If you are a ticket owner you should be able to view/modify but not take ownership of tickets in other queues. Permissions with multiple queues, as Airwolf, described is not that granular.
Posted by:
Acedashdog
12 years ago
Ah, no, I thought of that (not quite as dumb as I look!) there can be only one, and that one (apart from Admin the account) is me.
nshah, what you describe is what's happening (a user included in the label marked as Ticket Owner on any queue seems to get that privilege on any queue) but that's got to be wrong; if it was meant to work like that the option would be on the general options not per queue, surely?
nshah, what you describe is what's happening (a user included in the label marked as Ticket Owner on any queue seems to get that privilege on any queue) but that's got to be wrong; if it was meant to work like that the option would be on the general options not per queue, surely?
Posted by:
nshah
12 years ago
nope...that is the way it works. There currently isn't anything that will change that in the settings. You might want to use the green "Help" Button on the right on the GUI of the admin portal in the KBOX and submit a feature request.
Posted by:
Acedashdog
12 years ago
Ho hum. So if that's the case, I would be better off using Orgs instead of queues if I want control of my helpdesk workers, as presumably this doesn't operate across organizations?
Posted by:
nshah
12 years ago
You could but things to consider
1. separate queues or orgs mean different email address for ticket submission or training for staff on how to submit via GUI
2. Global reporting can be done across ORGS but they are separate DB's
3. multiple permissions settings and documenting
If there is a concern of other people changing or modifying tickets, remember that there is an audit log in every ticket on who made the changes and what was changed. You can take away their ability to delete tickets if you want to so they can't cover their tracks if you will. The decision is of course yours based on your environment and work flow. Hopefully you can outline the benefits and cons as ORG's might be a great short term fix but what long term issues might come up or vice versa for doing multiple queues.
1. separate queues or orgs mean different email address for ticket submission or training for staff on how to submit via GUI
2. Global reporting can be done across ORGS but they are separate DB's
3. multiple permissions settings and documenting
If there is a concern of other people changing or modifying tickets, remember that there is an audit log in every ticket on who made the changes and what was changed. You can take away their ability to delete tickets if you want to so they can't cover their tracks if you will. The decision is of course yours based on your environment and work flow. Hopefully you can outline the benefits and cons as ORG's might be a great short term fix but what long term issues might come up or vice versa for doing multiple queues.
Posted by:
cblake
12 years ago
Why do the helpdesk techs need into the admin portal? They can managed tickets in queues they are owners for via the user portal just fine.
Orgs is way overkill for separating some helpdesk tickets.
Orgs is way overkill for separating some helpdesk tickets.
Posted by:
nshah
12 years ago
I think the issue is that they can still see tickets of queues they are not owners of, even from the User Portal and no admin rights, just ticket owner labels and permissions to own tickets.
Posted by:
airwolf
12 years ago
Owners in one queue cannot do anything in another queue (cannot even see that it exists) unless they also have owner rights in that queue. If your tests prove otherwise, you should contact support.
EDIT: Obviously they can see the queue and submit tickets if they are a submitter, but as a submitter in a queue they are not an owner in, they can only see tickets they have submitted in the other queue.
EDIT: Obviously they can see the queue and submit tickets if they are a submitter, but as a submitter in a queue they are not an owner in, they can only see tickets they have submitted in the other queue.
Posted by:
nshah
12 years ago
Airwolf - in our tests you could see tickets in other queues and work and modify them but not take ownership. Unless something has changed, we have see that on our own and with other clients.
Posted by:
Acedashdog
12 years ago
Hm - I have my upgrade to 5.3 booked for Wednesday... I'll do that first and then retest and see if anything changes. If it doesn't, I'll log a call!
Posted by:
airwolf
12 years ago
ORIGINAL: nshah
Airwolf - in our tests you could see tickets in other queues and work and modify them but not take ownership. Unless something has changed, we have see that on our own and with other clients.
If this is true, you've found a bug.
Posted by:
Acedashdog
12 years ago
Why do the helpdesk techs need into the admin portal? They can managed tickets in queues they are owners for via the user portal just fine. Orgs is way overkill for separating some helpdesk tickets.
New tickets come in as Unassigned, and low-priv users can't see those in the User Console. So they'd depend on me assigning them to them which would be a drag, specially for AMS who are +1 hour.
Posted by:
Acedashdog
12 years ago
OK, today I did my 5.3 upgrade - smooth as a smooth thing - and this still seems to be happening; Ticket Owners for any queue can edit any ticket in any queue. So it does look like a bug, and I'll log it as such.
Thanks all
Thanks all
Posted by:
Acedashdog
12 years ago
Update to this
Preparing to launch a queue for a user department, and this has brought me up against a dilemma.
- If I leave the support techs for New Queue with just the user interface, they can't see Unassigned tickets in their queue and therefore can't pick them up. Not good.
- If I make them Ticket Owners in their own queue, they (thanks to the bug) gain Ticket Owner status on all queues in my helpdesk, not good.
Urmmmmm.... [:@]
I'll report the bug and hope for a fix...
Preparing to launch a queue for a user department, and this has brought me up against a dilemma.
- If I leave the support techs for New Queue with just the user interface, they can't see Unassigned tickets in their queue and therefore can't pick them up. Not good.
- If I make them Ticket Owners in their own queue, they (thanks to the bug) gain Ticket Owner status on all queues in my helpdesk, not good.
Urmmmmm.... [:@]
I'll report the bug and hope for a fix...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.