If there is an existing flavour that has almost the settings that you require, you can use this as a source from which to clone a new flavour. Click the clone icon on the popup header; this will create a new flavour, allowing you to enter a new name and modify settings from the starting point as desired before saving.
If none of the existing flavours meet your requirements you may need to create a new flavour from scratch. Simply click on the ‘Create New’ link at the foot of any of the flavour pickers and enter information in the resuling flavour popup.
Validation: When creating / cloning a new flavour, the system will not allow you to save the new flavour until it is valid. Once you have entered the required information nfor a flavour to be valid, the popup heard will turn green to show this. You must provide a name for your flavour.
There are two reasons that a flavour will become locked down and will therefore not be modifiable:
If it is shared in or more other locations (you can see this via the ‘Used by’ number in the popup header.
If it is used in a live Ticket / Case / Action.
In addition to Name and Description, Due Date flavours are made up of the following attributes:
Clicking on Show Activity button in the ellipsis will show you the activity history of the Due Date Flavour. You can see when the Due Date Flavour was created and by who, as well as if any edits have been made to the Due Date Flavour, when they were made and by who.
There are several Due Date Methods available which allow you to set the start point for calculating the desired SLA for an activity. There are more Due Date methods available.
Watch the following video to find out about the due date methods that re available when configuring Tickets:
Additional Due Date methods are available when setting Due Dates for Cases and Actions, as schedules and parent work item / sub-work items data can be used. Watch this video to find out more:
An advanced option has been enabled for Due Date rules which allows for the use of Custom Data variables when setting time adjustments. Enabling the Advanced option when setting a Due Date rule will display an additional set of options in the ‘Adjust by’ section.
This will allow you to add / subtract a certain number of Hours/Days/Working Hours/Working Days by selecting from a dropdown of numeric custom data fields.
The due date method ‘From a Custom Date Time Field’ allows configuration of rules which allows end users to supply the base date/time value for the Due Date for the rule via a custom data field at runtime, when submitting a Case or Action. The custom field must be of type ‘DateTime’.
At least one Enate custom data field specifically of the date time type.
An Enate Custom Card must be configured with the aforementioned data field.
This card must be configured on the specific Action or Case you wish to set this rule for.
Please note: If a value for the field is not specified, the system will use the default value set on the custom data field in its place. This could be because the user does not fill in a value, or the field does not exist on the Work Item’s custom card.
The end result of this functionality is to allow direct adjustment of Work Item due dates by modifying custom data field values, i.e. setting a value on a card..
..modifies the Work Item due date:
This is only available when a unit of 'working hours' or 'working days' has been selected.
If this flag is set, whenever the due date calculation results in a value that would have been the very end point of a working day (e.g. Friday 5pm when a 9-5pm working calendar is in play), the system will instead return a value for the first working moment of the following working day e.g. Monday 9am.
This option is only available when a unit of 'working hours' or 'working days' has been selected.
Due Date method configuration includes a ‘Move to End of Day’ setting. When checked, the system will take the relevant date calculated based upon the rule’s settings, e.g. ‘add 5 working hours to start date’), and will set the due date to be the end of that working day.
For example, if the system calculates a due date of ‘11am’ on a particular day, clicking this attribute automatically shifts the value to end of that working day. The sequence of the logic here is important when understanding how date / time values are arrived at with this method. The logic sequence is as follows:
Run the "method"
Adjust by fixed (working) days/hours
Adjust by dynamic (working) days/hours
Add wait time if the option is selected (and if wait time exists).
If using working time then ensure the result is within working hours - moving to the start of the next working day if precisely at the end of a working day
Finally move to the end of the (working) day if selected.
This option is only available when a unit of 'working hours' or 'working days' has been selected.
Note: "Move to Next Morning if End of Day" and "Move to End of Day" are mutually exclusive.
Clicking on the 'References' tab of a flavour will show you where this Due Date rule is being used.
In order to encourage the use of standard approaches to running Tickets, Cases and Actions through your business processes, Builder’s configuration approach encourages the re-use of related attributes which are grouped together into areas which define who work goes to, when it is due, what the follow up rules are, as well as some more general settings.
For each of these areas you are encouraged to create a standard menu of options which can be mixed together as standard ‘flavours’, providing flexibility in Service delivery without the need for bespoke support of a large number of ways of doing things.
Underpinning each of these selectable flavours are more detailed settings, but you should not need to manage your configuration at such a detailed level on a day-to-day basis.
After the initial work has been done when you first set up your system to create a standard menu of different allocation options, due date options, general settings and follow up settings, you should not need to access the detailed flavour screens very frequently.
Note: the creation of new bespoke Due Date methods and Allocation methods is no longer supported.
By far the most frequent interaction you will have with flavours is for Tickets and Actions.
Add a category row, choose your three flavours from the dropdown lists:
Who does it go to?
When is it due?
Follow up settings
And you’re done.
Add an Action row, choose your three flavours from the dropdown lists:
Who does it go to?
When is it due?
General settings
And you’re done.
Cases can be set to remain open for a specified number of days. Within this window, the Case can be re-opened based on client feedback.
The number of days the Case will remain open for can be configured in Builder in the “Case Info” tab.
Note: The number of days specified will be considered to be calendar days or working days depending on whether the Due Date Flavour used by the Case references a Calendar.
A Case will automatically re-open if (during the feedback window) an email is received or a Ticket is merged into it. A Case can manually be re-opened by a user using the “Reopen” button which presents on a completed Case which is within its feedback window.
Setting
Description
Due Date Method
Various standard methods of calculating a due date can be selected from, Depending upon the method selected, additional parameters may be required, e.g. a specific schedule. See here for more information about Due Date Methods.
Adjust by
Add or subtract a specified number of hours/working hours/day/working days (including minutes) from the starting date determined by the Due Date method selected, e.g. the Case start date.
Advanced
If set, further options are available (see following section)
Calendar
If using working days / hours, you need to specify which calendar to use for the calculation. This can either be the supplier / customer calendar linked to the contract (there must be one if you select this option), or a standard system calendar.
Relevant only for working hours / days.
Allow Override
This setting governs whether Service agent can override the due date for a Case when they start a Case from the Ticket Screen or Case screen.
Add Wait Time To Due Date
If set, stops the SLA clock whenever the item is put into a waiting state.
Move To Next Morning If End Of Day
If set, once the due date/time has been calculated, the time will be pushed to the first working moment of the following working day (This allows you to set a calculated Due Date of '5pm Friday' to be '9am Monday', assuming working calendars are set accordingly).
Move To End Of Day
If set, once the due date/time has been calculated, the time will be pushed to the end of the calculated day.
Method
Notes / Further Variables
First Day of Current Month
Fixed Day of Current Month
Set a specific day, e.g. ‘14’
Fixed Day of Fixed Month
Set a specific day and month, e.g. ‘14’ and ‘3’. Please note that if the month and day configured using a 'Fixed day of fixed month' due date method on a Case/Action/Ticket is earlier than the work item's start date, then the system will assume that the Case/Action/Ticket is due in the following year. For example, if the fixed day of fixed month value configured in the due date of a Ticket is 14th March 2022 but the Ticket's created/start date is 16th July 2022, then the system will assume that the Ticket's due date will be 14th March 2023.
Fixed Day of Fixed Month of Work Item Start Year
Sets a specific day and month and year. The year is calculated as the year the work item was started.
It is different to the already existing 'Fixed Day of Fixed Month' due date method as it will set the due date of the work item as the same year as when the work item get started. For example, if a Ticket's due date is 14th March 2022 but the Ticket gets started on 16th July 2022, then the system will assume that the Ticket's due date is the same year as when the Ticket was started, so it will assume that the Ticket's due date is 14th March 2022.
From a Custom Date Time Field
If any field of type Date Time is linked to the work item configuration, you can select it here. At run time, when this value is set / changed, the Due Date will be calculated.
From Packet Start Date
The date the Ticket was first created.
Initial Request Date
If a further work item has been created from an original request (when a Sub Case is created, when a Ticket is converted into a Case, when a Case or Action gets reworked, when an Action is created via the 'Start Action' option or when a new linked work item is created), this due date method captures the start date of the original request, allowing you to capture the entire length of time it has taken to complete a request, as opposed to just the length of time an individual work item has been being worked on.
Last Day of Current Month
Method
Notes / Further Variables
First Day of Current Month
First Day of Month from Explicit Schedule Date
Requires a Schedule linked to the Case. Supply a Schedule Date, e.g. “Key Date 1”, “Key Date 2” etc. from the dates list.
Fixed Day of Current Month
Set a specific day, e.g. ‘14’
Fixed Day of Fixed Month
Set a specific day and month, e.g. ‘14’ and ‘3’. Please note that if the month and day configured using a 'Fixed day of fixed month' due date method on a Case/Action/Ticket is earlier than the work item's start date, then the system will assume that the Case/Action/Ticket is due in the following year. For example, if the fixed day of fixed month value configured in the due date of a Case is 14th March 2022 but the Ticket's created/start date is 16th July 2022, then the system will assume that the Case's due date will be 14th March 2023.
Fixed Day of Fixed Month of Work Item Start Year
Sets a specific day and month and year. The year is calculated as the year the work item was started.
It is different to the already existing 'Fixed Day of Fixed Month' due date method as it will set the due date of the work item as the same year as when the work item get started. For example, if a Case's due date is 14th March 2022 but the Case gets started on 16th July 2022, then the system will assume that the Case's due date is the same year as when the Case was started, so it will assume that the Case's due date is 14th March 2022.
From a Custom Date Time Field
If any field of type Date Time is linked to the work item configuration, you can select it here. At run time, when this value is set / changed, the Due Date will be calculated.
From an Explicit Schedule Date
Requires a Schedule linked to the Case. Supply a Schedule Date, e.g. “Key Date 1”, “Key Date 2” etc. from the dates list.
From Packet Start Date
The date the Work Item was first created. Important note: for Actions this means this would be from the beginning of the Action, not its parent Case. If you wish to drive an Action’s Due Date from the Case, use ‘From Parent Packet Start Date’.
From Parent Packet Due Date
For Actions, the date its parent Case is Due
From Parent Packet Start Date
For Actions, the date its parent Case started
From Schedule Date Linked to Step
Requires a Schedule linked to the Case. Requires a Schedule Date e.g. “Key Date 1”, “Key Date 2” etc. from the dates list to be set for the Step this Action appears in.
Initial Request Date
If a further work item has been created from an original request (when a Sub Case is created, when a Ticket is converted into a Case, when a Case or Action gets reworked, when an Action is created via the 'Start Action' option or when a new linked work item is created), this due date method captures the start date of the original request, allowing you to capture the entire length of time it has taken to complete a request, as opposed to just the length of time an individual work item has been being worked on.
Last Day of Current Month
Last Day of Month from Explicit Schedule Date
Requires a Schedule linked to the Case. Supply a Schedule Date, e.g. “Key Date 1”, “Key Date 2” etc. from the dates list.
There are several allocation options available which allow you to route work items to the most appropriate resources for your business. These allocation options are defined when configuring your processes in Enate Builder.
Watch the following video to find out more about allocation options in Enate.
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 the 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.
To configure a new allocation flavour, click to add a new allocation. Alternatively, you can click to clone an existing allocation flavour and adjust the settings for the new allocation flavour from there.
This will bring up the Allocation pop-up where you will need to enter a name and description for the new allocation flavour, as well as the Queue, Queue Method and Primary allocoation method for it.
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 new 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.
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.
If you are using ‘push’ allocations where work is directly allocated straight to a user, you should then select an allocation method to determine position or team to allocate the work to.
This can be configured in the Allocation pop-up of a work item.
There are a number of standard methods available to choose from and, depending upon the method selected, additional parameters may be required. There is more detailed information for each of these options below.
Watch this video for more information about setting primary and secondary allocation methods.
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.
Simply select the particular Action Type from the resulting dropdown.
This allocation method lets you allocates work based on a contact tag. At runtime, the 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.
Simply select the desired contact tag from the resulting dropdown. The list of contact tags you can can choose from are defined in the General Settings section of Builder.
This allocation method will allocate work items to an individual in a particular User Group based on a round robin basis i.e. user 1, then user 2, then user 3, then user 1 etc.
Simply select the desired User Group from the resulting dropdown. The list of User Groups you can can choose from are defined in the User Management section of Builder.
This allocation method allocates work items to an individual in a particular User Group who has the lowest amount of estimated hours of work in their inbox.
Simply select the desired User Group from the resulting dropdown. The list of User Groups you can can choose from are defined in the User Management section of Builder.
This allocation method allocates work items to the owner of the parent work item. This allocation method is often used to ‘escalate’ Actions up to the Case owner.
This allocation method allocates work items to the user who started the parent work item.
This allocation method allocates work items to an individual based on the username supplied at runtime in a custom data field.
Simply select the desired Custom Data Field from the resulting dropdown.
This allocation method allocates a work item to the user who started the work item.
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.
Further general settings are set for Actions in the Action info grid.
General Settings attributes have been grouped together and standard combinations of them are shared but not completely globally (i.e. not between Cases, Ticket, Actions like the other types of flavours). Instead, these are shared for an individual Action type, i.e. shared among anywhere that a specific Action you pick from the menu of Actions is used.
General Settings flavours are made up of the following attributes:
Setting
Description
Name
Name of the allocation method. This name will subsequently be seen in the selection dropdown.
Description
Description for the allocation flavour.
Queue Method
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 more details.
Queue
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 further information.
Primary
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. See here for more information about allocation methods.
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.
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.
Setting
Description
Instructions
You can enter text instructions for that specific Action which end-users need to follow. This will be displayed on the Action form.
SOP URL:
Customers can put their Standard Operating Procedure on e.g. their intranet, and that link can be provided here. This allows our customers to have specific SOP’s for different Action. If a URL is entered here, a direct link is be provided on the form. Please enter a full url.
Autocomplete on Timeout
If ticked, this Action gets automatically completed after it has timed out.
Hide Case Link
By checking this checkbox user can hide the hyperlink leading to the Case it belongs to.
Pause Case if this Action is paused
On checking this checkbox, the whole Case Processes’ SLA clock pauses if this Action is kept on Hold for some reason.
Record Count
How the Record Count should behave on this Action. Options are:
Hide – Record Count doesn’t show on the Action.
Show – Update Case Value - the Record Count will show on the Action and whenever this value is changed on that Action, it will also update the Record Count on its parent Case.
Show – Do not update Case - the Record Count will show on the Action, but whenever this value is changed on that Action, the Record Count on is parent Case will not be updated.
Estimated Duration
Estimated amount of time in minutes that it takes to complete this Action. This can be in increments of a minute or whole minutes, e.g. 3.5 minutes, 124 minutes etc.
Can be Performed by Robotics Group
If you have Robot Farm groups set up (done via user Manager), you can specify whether an Action can be performed by a Robot group, and which specific group that is.
Estimated Robot Duration
If you have a Robot group selected, you can specify how long is the estimated amount of time take for a robot to carry out this task. This can be in increments of a minute or whole minutes, e.g. 3.5 minutes, 124 minutes etc.
Skills
This is a list of skills which are required to perform this task, and are used for MI purposes to help identify Activities which are ripe for automating.
MULTIPLE SKILLS CAN BE SELECTED FROM THE LIST.
