Service Manager Queues - Good or Bad?
Service Manager Queues are used by many organisations and are a supported way of getting some security or data separation into Service Manager. The decision to use Queues will depend on the business processes, organisation goals and analyst practices that you are trying to meet. This blog post will outline some the considerations around using Queues.
What is a Service Manager Queue?
Essentially it is a way of grouping SCSM objects together using a query. They are easy to define and are a useful way to separate different support groups from one another. Objects can belong to multiple queues, but I would be very careful doing this in a production environment - it just gets to confusing and complicated.
How do they work?
This is where the problems start to apply. They are implemented as a workflow that evaluates any new or updated object to see if it meets the Queue query criteria. This means there is a timing delay from when an object is created or updated before the workflow is run and the Queue criteria evaluated.
When the workflow runs, it will take the focus of the object away from any other process that is using the object e.g. if an analyst has an Incident open, when the workflow runs they will lose the current focus and will not be able to save the changes they are making. Microsoft have improved this, but it still happens enough that it makes analysts unhappy.
Why do Organisations use them?
They are the only way to provide some degree of data security (but really only separation) in Service Manager. There are a number of times where a support group will be handling sensitive requests that they do not want other analysts to be able to see. Usually these are HR or Finance related - no one wants pay details available to other analysts.
Limitations of the Queue Data Separation
The data separation provided by Queues only extends to the Operational database, ie the data in the SCSM console. But it does not extend to the data warehouse - if an analyst can run a query against the data warehouse they will be able to retrieve all data as the queue status is not used in the data warehouse. Thus when using queues, access to the data warehouse needs to be controlled and specific queries and reports developed that reflect the data separation implemented by Queues on the Operational database.
Why do Analysts dislike Queues?
By using Queues Analysts can "lose" jobs. The obvious way is to reclassify or reassign an Incident to another team that has a Queue applied to their jobs. After the workflow runs, the original analyst will not be able to see or retrieve the Incident. The only way to get this back is to ask the new team to reclassify or reassign the Incident back.
The less obvious way is when the Service Desk logs a call from a client and assigns it to the team that uses Queues. The analysts hits apply during the interaction and while they still need to add data. The workflow will run and can then essentially lock them out of the record as the Queue filter is now applying.
The most frustrating example of this is when the HR Help Desk (using Queues) creates the Incident and then hits apply. In this case they can actually lose access to the Incident while it is waiting for the workflow to apply. Only after it has applied and assigned the Incident to the HR Queue will they be able to edit the Incident again.
These can be solved by business processes, but they tend to annoy analysts that are just trying to get the job done.
Is there a better way?
Not really. If you have to have data separation between analysts there only Queues or separate SCSM instances. Again it will depend on the your specific requirements to make the decision.
My preference is to use a separate instance of SCSM when data security is required. It implements a real security boundary, as an analyst can only query the instance they use. But it requires more hardware, more management and can cause issues transferring jobs between instances. Check out Xapity Transfer to solve the transfer issue.
Every time I have used Queues to separate data, Analysts have complained about losing jobs or losing changes to jobs when the workflow applied. But sometimes there is no choice and the business areas will not fund a separate instance or need the integration with existing support groups (usually where they can see others data, but no one can see theirs).