Allocation Flavours
Last updated
Last updated
There are several Allocation Methods available which allow you to route work items to the appropriate resources.
There are two main approaches to allocating work in Enate, these are ‘Pull’ Approach and ‘Push’ Approach:
Pull Approach – work gets routed to Work Queues. This allows a) the work to be visible to the Manager(s) of that Queue and b) for people working out of that Queue to be allocated unassigned work items from it when they next bit the ‘Get more work from Queue’ button in their Enate Inbox. To use the Pull approach, you specify to allocate to a Queue, and then leave the Primary / Secondary allocations blank.
Push Approach – works gets routed directly to a user, either because of a specific user allocation, or to a position (from which the system selects one of th users holding that position). To use a Push approach, you specify and Primary (and, if you would want a backup in case no users are found with first rule, a Secondary) allocation.
Note: that when specifying a Push allocation it’s still highly recommended to specify a Queue allocation so that the work is linked to a Queue. If you do not, and the work becomes unassigned, the Team Leader will lose visibility of the Work item.
In addition to name and description, Allocation rules are made up of the following attributes:
Setting
Description
Name
A Name which will subsequently be seen in the selection dropdown.
Description
Queue Method
Queue
Primary
Inform Via Email
For Push allocations, whether to send an email to the person who the work is allocated to.
CC on Emails to all Primary Position
For Push Allocations, whether to email every person who occupies the position being used to determine someone to allocate to.
The following video shows you how to create Queues and set Queue methods.
You can create a new queue from here by clicking on the 'plus' icon from the Queue dropdown.
Enter the ne queue's name and hit 'Create'.
This newly added queue will be automatically selected.
Please note that you can't delete and edit queues here, this can only be done from the system-settings.
Method
Notes / Further Variables
From Queue by Name
Select a Queue from the dropdown
From Queue by Name and Team
Select a Queue from the dropdown.
This method is used when you have a very large number of Queues you might have to configure, e.g. a different Queue for each contract but you have a thousand contracts.
To use this method you should first create a Queue in the general settings section with a name which will be used as a suffix to the eventually used Queue name, e.g. ‘+L1’.
The system will use this information and will then auto-generate a new Queue for you with the text specified in the ‘Team’ attribute of the Contract (see Service Matrix section). e.g. if you set a name of ‘ACMEContract’ in the ‘Team’ attribute of a Contract, the system will autogenerate a Queue called ‘ACMEContract +L1.
This method saves large amounts of effort having to manually create and maintain the Queues – instead they are auto-generated based on this information.
Method
Notes / Further Variables
Completer of Previous Action
Select a Queue from the dropdown. Work items will be allocated to the user who completed the previous Action.
Contact Tags
Individual from User Group
Work items will be allocated to an individual in the selected User Group based on a round robin basis i.e. user 1, then user 2, then user 3, then user 1 etc.
Individual from User Group (by capacity)
Work items will be allocated to an individual in the selected User Group who has the lowest amount of estimated hours of work in their inbox
Parent Work Item Owner
Work items will be allocated to the owner of the parent work item. This allocation method is often used to ‘escalate’ Actions up to the case owner.
Parent Work Item Starter
Work items will be allocated to the user who started the parent work item.
Username from Custom Data Field
Work items will be allocated to an individual based on the name supplied at runtime as a custom field value.
Work Item Starter
Work items will be allocated to the user who started the work item.
With this allocation method, you can allocate certain Actions to the user who completed the previous Action. By doing so it decreases the load on the Queue and directly assigns the Work Item to a specified user as per config.
You can configure this type of allocation by selecting the Completer of Previous Action allocation method and selecting a particular Action as shown.
With this allocation method you can pass a username to be allocated to via a custom data field within your process.
Clicking on Show Activity button in the ellipsis will show you the activity history of the Allocation Flavour. You can see when the Allocation Flavour was created and by who, as well as if any edits have been made to the Allocation Flavour, when they were made and by who.
Clicking on the 'References' tab of a flavour will show you where this Allocation rule is being used.
For Pull allocations: There are two methods through which Queues can be determined: By Queue Name alone (you then just select from a list of Queues), or by the Queue Name for a specific Team. See here for .
For use with the standard ‘Pull’ allocation approach. This determines the Queue into which this Work Item should be allocated. The majority of allocations should use this pull approach where work is sent to a Queue and agents then pull work from this Queue when they are available to perform the activity. You can also create a new queue from here, see here for .
If you are using ‘push’ allocation – where work is more directly allocated straight to a user, this is where you set the allocation method used for determining which positions or team to allocate the work to. A number of standard methods are available to choose from. Depending upon the method selected, additional parameters may be required to be specified, e.g. a position from the position picker provided. See here for .
Allocates work based on a contact tag which you select from the resulting dropdown. The list of contact tags you can can choose from are defined in the . At runtime, system will look for users associated with the work item which have been tagged with the configured user type tag, and allocate the work to them. If multiple users share this tag, the system will select the user with the least amount of work items in their inbox to allocate to.