The Classic Service Dispatcher is a powerful tool to sort tickets into the right center of competence (queue) by looking primarily on the ticket service and the company (customer) who opened the ticket.
The new Advanced Service Dispatcher brings full control on the execution order and allows filtering by additional conditions and Regular Expression matching for Services and Dynamic Fields, such that it is possible to have a minimal set of needed Service Dispatchers.
Filtering by Dynamic Field Value
One of the most exciting new features is the possibility to filter by the value of a selected Dynamic Field. This allows to apply several different strategies when creating Service Dispatchers. One possibility is to allow or disallow Dispatching for certain tickets by having a Dynamic Field called anything like ‘Dispatch’ with two possible values ‘Yes’ and ‘No’. If every Service Dispatcher has the Dynamic Field condition set to ‘Yes’, we already reached our goal.
Another possible strategy is to filter by an already existing Dynamic Field like ‘Category’ and thus increasing the matching granularity. As Dynamic Field conditions are Regular Expressions, we can easily group various Dynamic Field Values into one Service Dispatcher*. (e.g. ^Incident|^Service\sRequest or ^\[01\d+\]\sBusinessApplication which will match anything like ‘[01X] BusinessApplication::NextLevel’ where X stands for any series of numbers)
*Keep in mind that working with Regular Expressions forces you to escape the following characters to match them:
\ . [ ] { } ( ) * + – ? ^ $ |
Chosing a dispatching strategy
With the new possibilities to match Services by Regular Expression and any Company it is possible to reach one Service Dispatcher per Destination Queue, Service and Company. I found that in most cases a very limited set of service dispatchers is needed as most of the time tickets from different companies with the same service have to end up in the same destination queue.
Experience showed that the system ends up very clean when we start from only one source queue ‘[N] Dispatcher’, handling exceptions first, and then dispatching the whole big rest in few simple Service Dispatchers to their respective destination queues.
Example
{Simplified Situation}
Companies: Company1, Company2 and Company3
Services: Hardware::Malfunction, Hardware::Replacement, Hardware::ServiceRequest
Queues: [N]Dispatcher, [0]ServiceDesk, [0]ServiceDesk::External
Every Ticket with a Hardware Service should be moved to the [0]ServiceDesk Queue, except for Company1 as they wanted third party Hardware.
The Service Regular Expression could look like this: ^Hardware
Alternative 1: One could now dispatch all Tickets for any Company to [0]ServiceDesk.
Then create a second Service Dispatcher with Source [0]ServiceDesk
and let Tickets from Company1 be Dispatched to Queue [0]ServiceDesk::External
thus having multiple Source Queues.
This is entirely possible but very soon the route taken from tickets become hardly understandable for humans, furthermore if repeated several times the risk of creating an infinite loop becomes high.
Alternative 2: Instead it is less confusing to have two Service Dispatchers with Source Queue [N]Dispatcher.
The first for Company1 and ^Hardware Service to [0]ServiceDesk::External
The second for <ANY> Company and ^Hardware Service to [0]ServiceDesk.
Benjamin Gröber
Author
