limit on queues

Gerhard_Goossens

Good day everyone,

I have a question regarding queues in Service Manager. I have come across many articles "including official MS documentation" suggesting to keep the number of queues to a minimum due to the extra load it puts on the workflow server.

So what I'm after is how everyone manages the access to the work items. I have seen Cireson videos where there is a queue for Finance that includes everything finance and then there is a queue for everyone else.

What I want is to limit what everyone can see as it might not only be Finance that has sensitive information.

I am planning to add all our departments into Service Manager. I work at a University so it includes everything from IT, HR, Finance, Facilities, etc and all the sub-departments for students and staff. 

As you can see this will be a lot of queues and I want to plan this correctly so we don't have issues in the future.

I was thinking of creating a queue for all the top level departments as this will limit access to a degree, but I'm not sure if it is the best way to approach this.

What I have done this far is as follow:
Create AD groups for each sub-department and add the analysts to the relevant groups.
In lists create hierarchy of department\subdepartment for IR and SR
Create queue based IR and SR, and criteria are "Support group = Department\subdepartment"
Create group, included members is the AD group.
Create User role, select required queues, CI's, Catalog Groups, tasks, views templates and add the  AD group to users.

So far I have only added two departments and 4 sub-departments. But like mentioned earlier I'm planning to add the rest of the university departments soon.

I know this is a mouth full, but I would really appreciate your input on how you have implemented this in your environments as I can't really find any info on how to implement this besides "Keep the queues to a minimum"

Any input will be highly appreciated
Gerhard

Tom_Hendricks

This is a terrific question and I am glad you asked it.  As I am only in the beginning stages of planning to implement this here (it has not been a requirement yet, but will be soon), I can only add some preliminary thoughts to yours:

Microsoft should bold, underline, highlight, and add 50 exclamation points to that statement about keeping queues to a minimum.  The performance hit is staggering, if your system has a high number of concurrent users.  You probably won't notice it in your dev or test environments if there aren't many simultaneous testers, however.

So in the spirit of getting the most protection from the fewest number of queues, I am asking some of the following questions:

• Is it sufficient to classify ticket data along the lines of "sensitive, private, privileged" or some other such division, so that I could only create queues based on the sensitivity level of information, and not have to split it further by department/team/function/etc.?  This is a business question that will vary for everyone, of course.
• If the above is possible, I can add a classification enum to the tickets and develop a procedure for which should be selected, and base the queue on its value.  If it is not, or if my ticket category or support team already tells me what I need to know, then this is not even necessary.
• If data sensitivity is not a viable way to divide queues, then do I have certain support groups that need a queue, and all others would not belong to a queue?

In any scenario I have described or implied, this means that (most) teams can see each others' tickets.  This is not a problem for me in this environment, but might be for others.  As long as I wrap a queue around the most sensitive tickets, I do not mind if the rest are out in the open.

Again, I have not proven these thoughts in Production yet, but hopefully it helps to some degree.

Tom_Hendricks

This is a terrific question and I am glad you asked it.  As I am only in the beginning stages of planning to implement this here (it has not been a requirement yet, but will be soon), I can only add some preliminary thoughts to yours:

Microsoft should bold, underline, highlight, and add 50 exclamation points to that statement about keeping queues to a minimum.  The performance hit is staggering, if your system has a high number of concurrent users.  You probably won't notice it in your dev or test environments if there aren't many simultaneous testers, however.

So in the spirit of getting the most protection from the fewest number of queues, I am asking some of the following questions:

• Is it sufficient to classify ticket data along the lines of "sensitive, private, privileged" or some other such division, so that I could only create queues based on the sensitivity level of information, and not have to split it further by department/team/function/etc.?  This is a business question that will vary for everyone, of course.
• If the above is possible, I can add a classification enum to the tickets and develop a procedure for which should be selected, and base the queue on its value.  If it is not, or if my ticket category or support team already tells me what I need to know, then this is not even necessary.
• If data sensitivity is not a viable way to divide queues, then do I have certain support groups that need a queue, and all others would not belong to a queue?

In any scenario I have described or implied, this means that (most) teams can see each others' tickets.  This is not a problem for me in this environment, but might be for others.  As long as I wrap a queue around the most sensitive tickets, I do not mind if the rest are out in the open.

Again, I have not proven these thoughts in Production yet, but hopefully it helps to some degree.