An overview of the new features in v2022.5 of Enate
In this latest release we've added a few enhancements while we work on the upcoming Self Service release. These are focussed on improving how you can deal with Work items, for example slicker transition from Ticket to Case, and giving more flexibility when creating linked items.
We've added in some Builder improvements too which focus on better support for incoming emails. Plus we've created a brand new way that 3rd party system can integrate with Enate via Application Credentials. Check out this video overview of some these changes..
Check out these new features in more detail in the sections below..
Converting Ticket to Case - quicker more direct promoting of Tickets into Cases
Bulk Create - you can now download the Ticket & Case templates direct from the upload screen
More Flexible Linked Work Item creation - more choice on data to copy into Linked work items, and support for Linked tickets without contacts.
Improved Checklists - audit information now displayed for each check
Email Connector Fallbacks - reduce the number of unprocessed incoming mail with fallback routes for each Connector's primary email.
Note: This change may impact your ongoing configuration of Email Connectors - please read the detailed notes on this feature adjustment.
Restore Retired versions of Ticket & Case processes to quickly build back previous models for processes.
Email Routing by sender Company - reduce the email routing rules needed for larger clients.
Application Credentials - New method for 3rd party systems to integrate with Enate via APIs.
You can check out a list of the new Features, Enhancements & Bug Fixes we've included in this release in the following sections. For a more extensive list of changes including API changes, Data Warehouse Changes and any Breaking changes, see the dedicated RELEASE NOTES section.
We have made it quicker for users to convert a Tickets into a Cases. This functionality is useful when it becomes apparent during processing a Ticket query that the request is better handled as a Case.
To convert a Ticket into a Case, expand the settings card of a Ticket, select 'Convert to Case' and then select the Case process you want to convert the Ticket into.
The system will then bring up any relevant custom cards for that Case - just fill in any required data and then click on 'Start Case' in the info card.
If your system has been configured to allow you to override the due date upon Case creation, you can select a new due date here.
If your system has be configured to set a schedule for a new Case upon creation in work manager, you can select a schedule here.
You can choose to keep each separate Ticket with you by selecting 'Keep with me' in the settings card and you can choose to send an email to the primary contact for the Ticket informing them that the Ticket has been turned into a Case by selecting the 'Send Automated Emails' option.
Confirm the Ticket promotion up to a Case by clicking the button in the Info card:
You will see a confirmation messages informing you that the Ticket will be closed and replaced by a Case (with the same reference number, but a ‘-C’ ending).
The original Ticket does not form any further part of service delivery and will now be in a state of Waiting with a Resolution Method of 'Case Launched' with a link to that Case.
The original Ticket will move to a state of Closed when the Case that has been launched is Closed.
The new Case launched will be in a state of To Do.
We've adjusted the Bulk Create feature for creating multiple work items from excel file uploads. Specifically, the bulk create Excel templates needed for uploading are now downloadable direct from the create screen, making it more convenient to use.
The Bulk Create feature lets you create large numbers of Cases and/or Tickets via the uploading of data from Excel spreadsheets. You can find a link to the Bulk Create page in the ‘Bulk Create’ link in the ‘Create New Work Item’ dropdown.
This will bring up the Bulk Create screen in a new tab. From this screen select whether you want to bulk create Cases or Tickets. You can then download the relevant Excel template, populate it, then upload it to the page - making sure to fill in any mandatory fields beforehand.
You can download a template of the excel file. The excel templates available will conform to whichever language you currently have set in your Enate user preferences.
Once you have added the data into the excel file, save and close it, then on the Bulk Create screen click to select the file.
You can then choose if you want to allow work items with duplicate titles to be created by using the ‘Unique Title’ option. Leaving this option off allows work items with duplicate titles to be created. Switching this option on will ensure that any work item which is due to have the same title as another item in the upload file will fail validation.
Once you are happy, click on the ‘Upload’ button. This will upload your information about the Cases or Tickets from your file on-screen.
You will see the following information:
Total – the total number of items contained in the uploaded file that will be created
Created – the number of items that have been created successfully (this will be zero before you start to create)
Issues – the number of items with validation issues (these need to be fixed before the items can be successfully created)
Not Started – the number of items that are waiting to be created
Additionally, in the grid you will see that a 'Status' and 'Reference' column have been added - these will be filled in by the system when the items get created.
All you need to for now is to click ‘Create Items’ and the system will start creating your Cases/Tickets. The information displayed will update to show the number of items that have been successfully create and the reference numbers of the work items created.
The mandatory fields which must be filled in order to create a Case are:
Customer
Contract
Service
Case - the process name
Title - the title for the individual Case work item.
Note that the Primary Contact and Requester fields are only mandatory for a Case when the 'Make Contacts Mandatory' option is set to 'on' for the Case type you are bulk creating in the Service Lines screen in Builder. If you do want to fill these fields in, make sure to adhere to contact record requirements.
The mandatory fields which must be filled in order to create a Ticket are:
Customer
Contract
Service
Ticket - the process name
Title - the title for the individual Ticket
Ticket Description
Ticket Category Level 1
Ticket Category Level 2
Ticket Category Level 3
Primary contact - the main contact you are dealing with for this query. See section about contact record requirements.
Requester - the contact that raised the initial request. See section about contact record requirements.
Note that all data entered must match existing values in the system, otherwise validation errors will be displayed.
Any contact records used in a bulk create file i.e. Primary Contact, Requester, Subject and CC contacts must adhere to the following rules:
the email address of the contact must be used
the contact must already exist in the system
the contact must be scoped to the same customer that the Case/Ticket will be created under
Optional fields that can be filled in for both Tickets and Cases are:
Subject - the contact the work item is about. See section about contact record requirements.
CC email address(es) - any further contacts which can be copied on any correspondence. See section about contact record requirements. Also note that when adding two or more CC email addresses, please make sure to separate the addresses with a semi colon (;) with no spaces either side e.g. user.one@example.net;user.two@example.net.
Override Due Date - enter the new due date. See date formatting section.
Do Not Send Automated Emails To Contacts - whether or not you want to send system-automated emails, such as request acknowledgement emails, to the contacts of the work item. Enter 'True' or 'False', this also applies for languages other than English.
Please be aware that any dates entered must have the following formatting:
DD-MM-YYYY HH:MM
Note that hours and minutes entered can either be in the 24 hour system format i.e. 23:00 or in the 12 hour system format with an AM/PM after it i.e. 11:00 AM.
Valid date format examples:
25-05-2022 23:25
25-05-2022 11:25 PM
If you choose not to enter hours or minutes, the system will set a default time of 00:00.
You can also pass custom data fields into the Cases/Tickets as they are being created. To do this, add a column name which precisely matches the data field name in Enate. If any of these bespoke fields are marked as mandatory in your Case process configuration, you MUST supply a value in this field’s column for every row in the upload file (otherwise that row will fail validation and a Case will not be created for it).
Bulk create supports below list of custom field type:
Check Box
Date Only - see date formatting section.
Date and Time - see date formatting section.
Decimal Number
Email Address
List
Long Text
Multiple level list
Short Text
Whole Number
Bulk create does not support below custom field type:
Tables
Entity Relationship
Additionally, the following system property fields are not supported when bulk creating work:
Keep with me
Keep Action with me
Defects
Files
If you do have any validation errors, these will be highlighted in red and a ‘warning’ status icon will be displayed. If the input values are wrong throughout an entire column, validation errors will be displayed at the bottom of the grid e.g. if a field column is referenced in the upload file which does not exist in the system. If the input values are wrong for an individual row, a ‘warning’ status icon will be displayed at the start of the row and the individual validation errors will be highlighted in red. You will then need to modify the file, click to 'change file' and select to upload your updated file.
You can still proceed with creation of the valid Case items in your upload file. The system will skip over the invalid rows and confirm creation of the valid ones, but the invalid items will need to be resolved before they can be created. You can do this by modifying the file and then clicking to 'change file' and select to upload your updated file.
Click here to see the full list of potential validation errors for Bulk Create:
Bulk Create is also supported in all of the languages that Enate offers: French, German, Spanish, Portuguese Brazilian, Romanian, Polish, Hungarian and Russian.
Note: the bulk create template uploaded should be in the same language as the logged-in user’s preferred language. For example, if a Spanish user wants to upload a bulk create template, then the template they upload should be in Spanish.
Additionally, the column header values in the bulk create template should match the values that are configured in Enate Builder in the Localisations page. If the translations for fields like Primary contact, Requester, CC, Subject or any Custom Data Fields have been modified in the Localisations page, then the column headings in the bulk create template need to match these values.
It is now no longer mandatory to add a contact or the primary and requester tags to a contact when creating a new linked Ticket. You can still choose to add a contact if you wish.
This will allow you to create linked Tickets from an existing one, often for management of internal activity, and ensure that communications which are created as part of the new linked Ticket don't get sent to original service recipient (it's quite likely that you will not want to be constantly informing them of internal activity). removing the need to add any contacts to linked Tickets helps support this.
Things to note with this change:
For any existing Tickets or Tickets that have been created in other ways (e.g. from the Contact Activity page, via bulk create, via email etc.), it is still mandatory to add a contact and the primary and requester contact tags.
Case behaviour remains unchanged - it is not mandatory to add a contact when a Case is created, even if the Case has been created as a new linked Case, unless the 'Makes Contacts Mandatory' option in the Case type in the Service Line screen has been selected.
We've also improved how you can copy data across to new linked Tickets or Cases.
Previously, if users wanted to copy data across they had to copy all the defects, files, links and custom data from the original Case/Ticket with the new Case/Ticket they were creating.
Now we have separated this out and made it possible for users to choose which types of data they want to copy across to a new linked Case/Ticket and to only copy that data across. They can choose to copy:
Defects
Files (including tags & file notes)
Links (including tags & link notes)
Custom Data (e.g. custom data fields)
As per existing functionality, users are still able to copy across work item Communications, i.e. emails (including email attachments) and notes from the original Case/Ticket to the new linked Case/Ticket you are creating. Note that when choosing to copy communications, you will not only copy communications from the original work item, but you will also copy communications from the original work item's related group, e.g. its Actions if it was a Case, or the parent/child Ticket if it was from a split Ticket. Also note that making updates to the communications in the new linked Case/Ticket will NOT update the communications in the original Ticket/Case it was created from.
You can find out more about creating new linked work items here:
Action checklists have now been updated to also show:
The name of the person who last updated the item in the checklist, and
When this update was made
For more information about features in the Action screen, check out the link below:
We've made a change in v2022.5 to help reduce the number of unprocessed incoming emails. This involves an additional Builder setting - a mandatory Fallback Email Route which must be set for the primary email address of each Email Mailbox in your system.
This will ensure that any mails arriving to that connector which don't get handled by the various email routes configured will at least be handled by this fallback and will kick off the Case or Ticket it routes to.
Fallback Routes are defined in the Email Connector popup in the Email section of Builder. When setting a fallback route you can define:
The Work Item that should be created for an email coming into that connector (if not picked up by any other email routes), i.e. the specific Ticket or Case.
If Automated emails can be sent as acknowledgements when the work item is created.
If it should only create Test Work Items.
After your system has been upgraded to v2022.5, Email Connectors which do not yet have a fallback route defined will still work, and as such would still potentially allow some incoming emails to be unprocessed if they are not picked up by any of the existing email routes. However, you should be aware of the following when configuring Email Connectors after upgrade:
Any NEW Connectors which you create MUST have a Fallback Route specified in order to be saved and set live.
Any EXISTING Connectors which you EDIT MUST also have a Fallback Route specified in order for you to save your changes. The Save option will be disabled until you have specified a fallback route.
During the upgrade to 2022.5, Enate will assess all the existing Email Routes for each Connector in your system attempt to automatically set one of these for each Connector as its fallback route. In order to qualify as an acceptable fallback route, the email route must meet the following criteria:
Its email must match the primary email address or be set as a catch-all '*' wildcard.
No additional Routing Rules must exist for the Email Route.
It must have a Ticket or Case route already defined for it.
It must already be the last route in the ordered set of Routes for that Connector.
It must already be Enabled.
If an Email Route for a connector meets the above criteria, its route settings will be added to the Connector (displaying in the Connector details popup), and certain aspects of the Route's configuration will become locked down, in order to ensure it remains as the fallback route. See section below for details of this.
To add a fallback email route to an existing connector, click to edit the connector and then choose the Customer, Contract, Service and Process in which you want work items to be created in via your fallback route.
You can also choose whether you want to send automatic emails (such as request acknowledgement emails) to the work item's contact when a work item has been created via the fallback route by selecting the 'Send Automated Emails' option.
You can also choose whether you want your fallback email route to only create work items in Test Mode by selecting the 'Only create work in test mode' option.
Whether it be as a result of auto-selecting during upgrade, or manual definition of the email route afterwards within the Connector, the email routes which have been specified will then show in your Email routes section with some specific impacts. Details of this are as follows:
These routes will always display at the foot of the Email Routes list
The Routing Rule will be set to read-only
The Email Connector will be set to read-only
The 'Enable' setting is set to ON, and is read-only
We have added the ability for Builder users to restore retired versions of Case and Ticket process.
To do this, open the Case/Ticket process in edit mode in Builder, select the retired version you want to restore from the header dropdown, then click on 'Restore'.
When you restore a retired version, it will return it to a state of draft that you can then edit, save and set live.
Note that if you already have a draft version of the process in progress, any unsaved changes that you have made in it will be lost upon clicking 'Restore'.
We have added a further item to your Email Route routing rule options in Builder, called 'Sender's company name includes'. This option lets you direct incoming emails based on the company the email sender's Contact record belongs to. Using this option avoids you having to create multiple variations of slightly different email domain-based routings which you may have for your larger clients, e.g.
A set of multiple domain-based routing rules for '@acme-apac.com', '@acme-na.com',' @acme-eu.com' can simly be replaced by a single routing rule of 'Sender's company name includes ACME'.
To add an email route based on the sender's company, select the 'Sender's company name includes' routing rule option.
Then from the dropdown select the sender's company name. You are able to add multiple companies. Then click 'Update'.
Now any emails arriving from email addresses belonging to the companies you have selected will start the process set in the email route.
When adding a new Contact Tag in the Contact Tags section of the Settings page in Builder, we have renamed the option to show contact tags in the Contact Activity Page in Work Manager as 'Show in Contact Activity Page' from 'Show in Call Handling'. The option continues to work the same as before where if the option is switched on, when a user opens the Contact Activity page in Work Manager, any work items linked to this user via this relationship will display on their Activity tab.
When setting the maximum size allowed for outgoing emails in the General Settings section of the Settings page in Builder, it is now recommended that you configure the limit to 30% LESS than what you want your end-users to write as as an extra buffer to accommodate encoding etc. e.g. if you want the maximum size to be 100MB, we would recommend setting the limit to 70MB.
New approach for granting access for integration into Enate
As part of this release we're adding a new way in which third Party systems can access Enate - Application Credentials. We've added this to give developers a dedicated way to support how their APIs can be given access to the system. Using this approach for granting API access has some advantages over using standard user accounts:
A single set of application credentials can have multiple concurrent sessions active.
You can select specific levels of access to grant each set of application credentials, keeping permissions only as expansive as they need to be.
Allows a more appropriate support for system-to-system communication.
Gives better tracking of which APIs are accessed by third party applications.
In technical terms, this feature allows Builder admin users to create sets of credentials, specifically 'OAuth Client Credentials' to access Enate & call APIs. Enate uses OAuth2.0 (Open Authorization) for token-based authentication and authorization. For more information on OAuth2.0, please refer to this link https://oauth.net/2/.
The approach is as follows:
Use Enate to create an application Credential record (a specific 'ClientID & SecretKey' record, which is effectively a username & password).
External to Enate, you must call the Enate oAuth/Token API passing the client id and client secret to obtain a token (specifically a 'Bearer Token').
Ensure this Token is included in each API call which is made into the Enate system.
The integration approach uses a type of tokens called 'Bearer Tokens' to access the Enate APIs. These Bearer tokens use HTTPS security, and the request is not signed or encrypted: possession of the bearer token is considered authentication. For more about OAuth 2.0 access tokens, refer to this link https://oauth.net/2/access-tokens/.
Note that the bearer token will expire if it is not used to make an API call for the length of time set in the 'Idle Session Timeout' setting in the General Settings section of Enate Manager.
If the bearer token does expire, the application credentials can be re-authenticated by using the '/OAuth/Token' Enate API to generate a new bearer token.
Additionally, any changes made to a user's roles (i.e. if a user gets assigned a new role or they are removed from a role) will cause the bearer token to expire.
If a bearer token does expire, the application credentials can be re-authenticated by using the '/OAuth/Token' Enate API to generate a new bearer token. Note that revoked roles will not get assigned to a new bearer token.
To support this feature we've added a new section in the User Management section of Builder to help manage different sets of Application Credentials you may wish to create:
The resulting screen will show a list of any existing Application Credentials, the roles it includes and the expiry date. To create a new credential, click on '+' link, and fill in details in the resulting popup:
Enter a Name for the credential, add an expiration date and select which Role(s) which you with the credential to have - these are equivalents to various permissions roles which a user can be given access to. Options available are:
Service Agent
Able to access Work Manager - standard Team Member level access
Self Service User
Able to access Self Service app (available in future release)
Work Creator
Access to create new Cases, Tickets, Actions in Work manager
Work Assigner
Access to assign work items in Work Manager
Team Leader
Access to Team Leader-level data in Work Manager (e.g. bots view, Queues page).
Builder
Access to Builder
User Manager
Access to only User Management section of Builder
Master Builder
Access to create & edit master data which can be shared between processes
Release Manager
Ability to publish Case & Ticket processes in Builder
Additionally, if a user has been removed from a role, these revoked roles will appear in grey in the application credentials edit pop-up:
Then click to generate a key. This will create:
A Client ID
A Secret Key
You should copy these two pieces of data at this point, for use in subsequent steps to create a Bearer Token outside of Enate.
Note: You will only be able to access this secret key once, at this point. Once the pop-up window is closed you will no longer have access to it, and if you have not taken a note and subsequently wish to use this client ID, you would need to generate a new secret key.
Once the Credential record has been generated, it will be saved and stored in the Application Credentials page. You can subsequently edit its name and expiry date and generate a new secret key for it. Credential records can also be deleted if desired.
You should use the copied Client ID and Secret Key as inputs into your third party system, for example the Postman API testing tool. From example above, this would be:
Client ID: eba59171-ac3a-4527-939a-830494c2c5f6
Secret Key: 3@rn0i+0y5jRB8_n
The Third-party system should be making a POST API call to the '/OAuth/Token' Enate API to generate the bearer token.
For the API request, select 'x-www-form-urlencoded' in the body section to pass the three parameters below while making the API call to generate the token.
grant_type - client_credentials
client_id - 0f6c907b-00f4-4e12-8d75-41454b777533
client_secret - TLd55KNez61niSXO
Example:
This generates the Bearer token, which is then used to get authorization for API calls to Enate.
To make a new API call to Enate, select Type as ‘Bearer Token’ in the Authorization section of the API request, pass your generated bearer token and the request URL for the specific API you're looking for.
We will soon be releasing a brand new Self Service platform which will allow a much wider userbase to create & track their service requests into your service centres. To support enabling this upcoming Self Service option, we've made a few small changes to some of the Enate screens in Builder.
We have added a new setting to Cases to allow you to choose if you want the process to be available to Self Service users.
You can either enable the option from the Case menu on the Service Matrix screen.
You can also enable the Show in Self Service option from the Case screen itself. If the icon is highlighted in blue, the Case will be available to Self Service users; if the icon is grey, the Case will not be available to Self Service users.
The previous 'Employees' section in User Management in Builder has now been renamed 'Self Service Users'. Any previous 'Employees' will remain, they will simply be renamed as 'Self Service Users' and be accessible from the Self Service Users page.
Note that the Self Service Users page will only appear if you have a Self Service instance configured.
The Self Service Users page, accessed via the User Management section of Builder, is where you can add, edit and manage your Self Service users. Self Service users are the people who you are delivering service to and who are using Enate Self Service.
You can see a list of your existing Self Service users, and information such as their first name, last name, username, email address, company, when they last logged into Self Service, and whether or not they can view community requests i.e. if they can view all of the requests that have been submitted to their company in Self Service.
You can customise the order in which you want to view your Self Service users by clicking on each column header.
Additionally, you can choose to only show Self Service users that belong to a particular company by using the company filter option at the top of the page.
You can also use the search function at the top of the page.
To add a new self service user, go to the ‘Self Service Users’ page in Builder’s User Management section and click on the '+' icon at the top of the screen. This will bring up the ‘Add Self Service User’ pop-up where you can enter the person's details.
In the General tab you can add the following details:
Company
The organisation this user works for.
Mandatory. Note that once the user has been added, the company they belong to can no longer be changed.
Username
User’s username, with which they login to all Enate applications
Mandatory
First Name
User’s first name
Mandatory
Last Name
User’s last name
Optional
The user’s work email address
Mandatory
Language
User's preferred language
Optional
Time zone
The user’s local Time zone
Mandatory
Calendar
The working calendar for this user
Optional
Send Welcome Email
If you switch this on, the self service user will receive an automatic emails, such as a 'Welcome to Self Service' email and emails relating to the status of their submitted requests.
Optional
Can view community requests
If this option is switched on, the self service user can see community requests when they are logged into Self Service. This means that they can see requests submitted to their company.
Optional
In the Password tab you then need to set the self service user's password. Please note that passwords:
Should not contain the username, first name or surname of the user.
Should contain at least contain 8 characters.
Should not contain more than 16 characters.
You can edit the details of an existing user by clicking on the menu link on the right-hand side of the contact. All attributes can be modified with the exception of the Company to which they belong.
You can also see what edits have been made to a user account and when, as well as when the user account was created, by clicking on the Show Activity button.
You can delete a Self Service user by clicking on the menu link on the right-hand side of the contact.
Note: deleting a Self Service user is a logical delete only; the user account is effectively retired. The account can be reactivated at any point.
You are able to reactivate or "undelete" retired Self Service users by activating the system-wide ‘Show deleted items’ button. This will show you your retired users which will be greyed out in your grid. Clicking on the menu option of a retired user will shows you an option that allows you to reactivate that user account and set them as an active user.
You can reset the password of a Self Service user by clicking on the menu link on the right-hand side of the contact and selecting 'Change password'. You can then give them a new password as per password policy.
2022.5.6.0 is a HotFix release that contains a number of bug fixes for version 2022.5 of Enate.
There are no further enhancements, new breaking changes, additional breaking API changes of additional known issues for this release.
The change log for 2022.5.6.0. contains a detailed list of bug fixes which have been included in this release. A downloadable copy of the Bug Fixes Change Log is available below that contain all of the bug fixes for all of the 2022.5 builds up to 2022.5.6.0.
2022.5.5.0 is a HotFix release that contains a number of bug fixes and enhancements for version 2022.5 of Enate.
There are no new breaking changes, additional breaking API changes of additional known issues for this release.
The change log for 2022.5.5.0. contains a detailed list of the enhancements and bug fixes which have been included in this release. A downloadable copy of the New Features & Enhancements Change Log and the Bug Fixes Change Log are available below that contain all of the new features & enhancements and all of the bug fixes for all of the 2022.5 builds up to 2022.5.5.0.
2022.5.3.0 is a production release that contains a number of enhancements and bug fixes.
The change log for 2022.5.3.0 contains a detailed list of the enhancements and bug fixes which have been included in this release. A downloadable copy of the New Features & Enhancements Change Log and the Bug Fixes Change Log are available below.
Below is a document with details of all API Changes in 2022.5 including breaking API changes.
Below is a copy of the breaking changes document for v2022.5. This contains details for all breaking changes within the Data Warehouse and the Enate APIs.
This document lists all the validation codes for the 2022.5 release.
Recommendation for best use of API breaking changes documentation is as follows:
Read through the breaking changes information for APIs
Upon finding reference to an API which you currently use and which has changed, go to your Swagger environment for the quickest way to view the overall impact and new API content definition. Your Swagger environment should always be your go-to place for the definitive explanation of the current API structure. See the Swagger explanation in our main online Help section for more information.