Overview of Builder

Enate Builder allows you to deploy and configure new Services, Cases and Tickets for your customers quickly and easily. It allows you to set up standard reusable configurations which help support repeatability in your Service delivery.

This following sections will describe the features available to allow you to view the Services your customers receive (and which components of that Service are switched on for them, i.e. specific Cases and Tickets), configure these Cases and Ticket settings, create standard patterns of settings to be re-used, build Flows, and move these items from draft through to live operating business processes.

Here's a quick video that will introduce you to Builder:

Accessing Builder

You can access Builder by first logging into Work Manager. If you have been set up with ‘Can access Builder’ in your user setup (done by your user administrator, see here for more details), then you will have access to Builder from the navigation menu. This will open Builder up in a separate window.

Setting Levels of Access in Builder and Work Manager

These can all be found in the the 'Access' tab of the Edit User popup in the ‘See More’ section of an individual user in the User Management Screen.

The breakout of permission levels for a user to access Builder is as follows:

Can Edit Shared Configuration

This setting allows the user to modify core settings and shared data which are used in multiple places and so can have more wide-reaching impact when modified, as well as access to the following levels of configuration:

• Add/Edit Service Line

• Add/Edit Case/Ticket Archetype

• Add/Edit Action-Type in Global Menu

• Add/Edit/Clone of Flavours i.e. Due Date, Allocation, Action general, Ticket Follow Up

• Add/Edit Ticket Category Global List

• Add/edit Global Checklists

• Add/Edit Service Provider

• Add/Edit System Setting

• Add/Edit Calendar

• Add/Edit Custom Data and Fields

• Add/Edit Email Settings

• Add/Edit Schedule Structure

Can Access User Management

This setting allows you to specifically access the User Management and RPA Integration sections.

Can Set Live

You can use this attribute to help support segregation of capabilities - allowing you to specify that people who build processes in Builder aren't necessarily the same people who can set those processes live. This supports the existence of a 'Release Manager' role. This setting allows the user to access the following levels of configuration:

• Add/Edit Language translation

• Add/Edit Contract

• Add/Edit Service

• Add/Edit Case/Ticket into a Service

• Add/Edit Local checklist

• Add/Edit Customer

• Add/Edit Fixed Frequency Schedule

• Add/Edit Schedule records to Set Live and Retire

Navigation links to the various sections available in Builder are displayed in the toolbar down the left side of the screen.

The main sections of Builder to familiarise yourself with are as follows:

1. Service Lines Screen - this is where you can see, create and manage your service line master data.

2. Service Matrix Screen – this is where you can see a list of your customers and which Services they receive and where you can create new Cases and Ticketing processes under them.

3. User Management Screen – this is where you can create and maintain your Service Agents, Robots, Self Service Users, User Groups and Application Credentials.

4. Email Mailbox configuration - this is where you can set up your mailboxes, choose where work arriving in these mailboxes routes to, plus set up standard email templates and canned responses for use when composing emails in Work Manager.

5. Calendars – this is where you can define the working days, hours, national holidays into set calendars which you can then link to Customers and Contracts during their definition.

6. Custom Data – this is where you can create Custom Data Fields which can then be displayed on Cases, Ticket and Actions.

7. Custom Cards – this is where you can create Custom Cards which can then be displayed on Cases, Ticket and Actions.

8. Schedules – this is where you can create schedules of dates which can be used to manage delivery dates for activities in your cases (e.g. for payroll environments) and create repeating schedules to trigger Cases, allowing them to be launched automatically.

9. Localizations – this is where you can set localized values for your own data that has been created when designing your processes.

10. Marketplace - this is where you can access your integrations, such as your RPA connections (e.g. UiPath) and OCR integrations (e.g. ABBYY)

11. Settings – the is where you can adjust general settings which take effect at system-level.

You are able to create new types of Tickets and Actions within a Service Line itself by clicking on the '+' icon next to the search bar and selecting 'Ticket'.

Creating a new type of Ticket

When creating a Ticket, you can enter the following information:

Subsequent Editing of the Ticket Type

To edit a Ticket type’s settings, click on the Case / Action / Ticket in the Service Lines Screen and edit the information in the right hand side of the screen. Click to save these changes.

You are also able to see the activity history of your work items , by clicking on the Show Activity button. You can see when the work item was created and by who, as well as if any edits have been made to the work item, when they were made, as well as by who.

You are also able to clone a Ticket type by clicking on the Clone button in the edit screen. This will clone all of the Ticket type's settings and data apart from its name. You are able to make changes to any of the settings and data once the Ticket type has been cloned.

The Service Lines screen is where you can see, create and manage your service line data in one place.

Access this area by clicking on the Service Lines link in the Toolbar.

You can view all of your service lines by clicking on the drop-down menu. You can also add new Service lines in the same location.

Selecting a service line will show you the number of Cases, Actions and Tickets associated with that service line. The search bar allows you to search through the Cases, Action and Ticket processes associated with that service line.

Clicking on a particular Case, Action or Ticket associated with a service line will bring up the master date information for that Case, Action or Ticket in the right-hand side of the screen a to view / edit this information.

Creating a New Service Line

You can create a new service line by clicking on the '+' icon next to the dropdown menu.

Once you save your service line, it will appear in the drop-down list.

Creating Defect Categories

You are also able to create defect categories as part of the service line by clicking on the 'Show Advanced Settings' button. Defect categories are supported in three levels.

Accessing Ticket Categories from Service Line

In addition to being able to define your global menu of Ticket Categories within the individual Ticket configuration screens, you can also maintain it under the Service Line. access via the 'Open Ticket Categories' link and edit your Categories menu there.

Adding a Record Count to Cases and Tickets

When you are creating or editing a Case or category 3 Ticket on the Service Line Screen you will be able to enable record count. You will also be able to write a record count description that will be displayed for the Work Manager user. While the description is optional, it is recommended that you write one as it can make clear to Work Manager users how to use the record count.

Adding an Initial Estimated Effort Timer for Cases, Actions and Tickets

You can an an initial estimated effort timer to Cases, Actions and Tickets from the Service Line Screen. Case and Action effort estimation timers are set at type level. Ticket effort estimate timers are set a category three level.

Editing a Service Line

You can edit an existing service line by selecting that service line from the drop-down menu, making changes as desired and hitting 'Save'.

You can see what edits have been made to the Service Line and when, as well as when the Service Line was created, by clicking on the Show Activity button.

You are also able to clone a service line by clicking on the Clone button in the edit screen. This will clone all of the service line's settings apart from its name. You are able to make changes to any of the settings once the service line has been cloned.

Creating new Case and Ticket types

In addition to being able to create new and types from the , you are able also to create new Case and Ticket types from the itself. Click the '+' icon, select a Case or a Ticket and then fill out the required information in the resulting popup.

Creating new Ticket / Case Processes

This will take you to the Ticket or Case screen where you can begin configuration.

Different Configuration States of Case and Ticket

As you configure the settings of a new Case or Ticket, it can move through various states until it is ready to run Work Items through in Work Manager.

The key in the top right tells you the states of the Cases and Ticket processes.

Opening / Editing / Setting a Ticket or Case Live

Once a Case or Ticket exists, you can access it from the Services Matrix by clicking on it, which will open a dropdown list of options. The options listed vary depending on the state of the Case or the Ticket.

You can group work items in the Service Matrix by creating higher-level Process Groups into which you can nest multiple Cases/Tickets.

In order to create a Process Group, go to the Service Lines screen and then in the Case or Ticket you want to add to the group, define the name of the Process group:

When you switch over to the Service Matrix Screen, you will be able to see that your Cases and Tickets are now grouped. Clicking on a Process Group tab will reveal the Cases / Tickets within that Group.

A setting in General Setting lets you decide if you want to show or hide process group information in both Builder and Work Manager.

If the setting is off, all process group labels and fields will be hidden.

The Ticket screen allows you to set which Ticket categories are selectable when someone is submitting a Ticket, this could be an end user submitting a Self Service form, or a Service Centre agent taking a call.

Each new Ticket category you add will appear in the dropdown lists on the Ticket submission form at runtime. Ticket categories are three levels deep. You choose the categories from a master menu of Ticket categories.

Once you’ve added a category for this Ticket, you set the various attributes necessary to determine how it will act at runtime. Primarily you set ‘Who does it go to’ (i.e. which Queue, and perhaps which position), ‘When is it due’ and some further general settings. The options available for you to pick here are a standardised list of ‘Flavours’, shared between Case, Ticket and Action configuration.

Once you have finished setting these attributes, you can set the Ticket process live.

All that remains is to add an input channel in Configuration Manager to allow users to launch the Ticket, and you are ready to start delivering Service.

At runtime, the user will select the category as part of submission, and the system will subsequently know how to route the work, what behaviour it should have, and when it is due.

Add a Ticket Category from the Menu

Select the ‘+’ button on the top right of the page of a Ticket process in edit mode to bring up the Ticket Category menu.

Select a level 1, then 2, then 3 category from the list of available categories on the left-hand side.

Selecting any Level 1 category will select all of its Level 2 and 3 child categories. Selecting any Level 2 category will select all of its Level 3 child categories, as well as its parent Level 1 category and display. Selecting any Level 3 ticket categories will select its parent Level 1 and 2 categories.

Your selected categories will then be displayed on the right hand side.

Clicking on the ellipsis of a ticket category will show you options to edit and delete the category. The Show Activity button lets you see the activity history of the category - you can see when the category was created and by who and you can see if any subsequent edits have been made, when they were made and by who.

Creating a New Ticket Category

To create a new Ticket Category, click on the '+' icon underneath the existing Ticket Categories and give it a name.

Adding an Initial Estimated Effort Timer and Record Count to Tickets

When you are creating or editing a tier 3 ticket, you will be able to set an initial estimated effort per record timer and chose if you want the record count to be visible to Work Manager users working on that ticket. You will also be able to write a record count description that will be displayed for the Work Manager user. While the description is optional, it is recommended that you write one as it can make clear to Work Manager users how to use the record count.

Deleting a Category Row

Select one or more rows in the grid with the checkboxes in the leftmost column, click on the trashcan icon in the bottom right section to delete.

The customer, contract and service of the Ticket process is displayed on the top-left.

The 'Version' dropdown lets you choose which version of the Process you want. By default you will see the current draft (In Progress version), but can switch to the currently Live version and even previous now retired versions to compare process flow setup.

You can also restore a retired version of a Ticket process by opening the Ticket in edit mode, clicking on the retired version you want to restore, then clicking 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.

You can view the status of the Ticket from the 'Status' dropdown.

The 'Show Activity' button lets you see the previous activity for the Ticket Process. You can see who created/deleted/last edited the Ticket Process, so you know who to go to if you need further information. The information will be highlighted in Green if the object has been created, restored, enabled or set live; in yellow if the object has been updated; and in red if the object has been deleted, disabled or retired.

Any validation errors will be displayed with either a red or orange exclamation mark. Clicking on the icon will bring up a list of the validation errors. Clicking on the error itself will highlight the source of the errors where you can correct the information.

Any serious errors will be marked by a red exclamation mark, these need to be resolved before the Ticket Process can be saved.

You can see Custom Cards, Email Templates and Wait for Feedback that are related to the Ticket.

Clicking on the '+' button brings up the Ticket Category Menu where you can add new Ticket Categories.

If you have opened the process in view only mode, click on the blue Edit icon in the toolbar to allow changes to be made.

This will bring up the Save and copy buttons.

Testing Ticket Configuration

Once you are happy with your Ticket configuration, you can test it in Work Manager.

Setting a Ticket Live

To set a Ticket live, click 'Save'. If there are any validation issues, they will need to be sorted. Once you have saved any further changes, you can now set the Ticket live.

You can also set a Ticket live from the Service Matrix Screen, provided it is in a state of Validated Changes, or Live with Validated Changes:

Ticket Feedback

Once you are happy with your Ticket categories, you need to set the following attributes for each category in the table on the Ticket screen:

*mandatory in order to set live.

You can copy and paste attributes in the Ticket Screen. You can select data from multiple cells and paste that data into selected destination cells.

If you are copying just one cell from each column, you can paste it in any number of places:

If you want to copy more that one cell from multiple columns, you must copy the same number of cells from each column:

If the number of cells you select to paste data in is more than the number of cells you have copied, the data you have copied will repeat itself to fill the highlighted cells.

If the number of cells you select to paste data in is less than the number of cells you have copied, you will only paste data to fill the highlighted cells i.e. if you copy the data from 4 cells but select to paste that data into 3 cells, then only the data from the first 3 cells you copied will be pasted.

If you select to paste data into multiple places, the data that is pasted will begin from the start of the first cell you copied.

The data from the first cell you select will be pasted first:

Upon opening the Ticket configuration screen, if you have not yet started to add any Ticket category definitions you will be met with the ‘Clone’ popup. This lets you copy categories and configurations from existing Tickets. Processes from a different Ticket type will be highlighted in grey with a yellow border.

You can filter the processes by customer, contract and service. Contract options will be based the customer selection and the service options will be based on the customer and contract selections.

The Same Process Types Only toggle lets you choose to only view Ticket processes that have the same process type. It is disabled by default.

Once you have selected a source, the categories and configurations from that existing Ticket will be cloned into your new Ticket's screen.

Overview

Peer Review Actions are a great way for different members of a team to crosscheck each other's work for key actions within a case, letting you embed quality checks into your processes without having to add in feedback flows.

Enate supports this with a 'Manual with Peer Review' Action type that you can add to your Case flows. These are like 'Manual' Action types, except that once the initial manual activity is carried out by a user, Enate will route the Action to be picked up by a different user to check the work, passing or failing it. If failed, it will route back to the original user to resolve the issues.

Watch this video to find out more about how to set up a Peer Review Action:

Click here for more information and examples about when and why you would user Peer Review Actions.

For detailed information on how Peer Review Actions work at runtime, see the dedicated Work Manager section.

Creating a Peer Review Action Type

You can either create a Peer Review Action type in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating a Peer Review Action type from the Service Lines page adds the Action type to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Line page, select which service line you would like to add the peer review Action to and then click on the plus symbol next to the 'Process Search' box. This will bring up a drop down menu where you can select an Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the type drop down select 'Manual Action with Peer Review'.

You can then choose to add a global checklist to the Action. This contains a standard checklist of activities that will be added any time this Action type is added to a Case flow. See here for more information on checklists.

You can also choose to add a Peer Reviewer global checklist to the Action. This contains a standard checklist of activities for the peer reviewer to complete that will be added any time this Action type is added to a Case flow. See here for more information on peer review checklists.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively you can add an Peer Review Action type directly from the Case flow itself.

To do this, open a Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its type, select 'Manual with Peer Review Action'.

This will add the Peer Review Action to the Case flow.

Configuring Peer Review Actions

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the usual following information for an Action:

Additionally, once a Peer Review Action has been added to your Case flow, a new 'Peer Review' tab will display in the info grid.

Here you need to add the following settings that are only relevant for the Action once it is in its 'Peer Review' stage.

Peer Review Checklists

You can set up Peer Review Actions to display a dedicated checklist for the peer review section of the Action. These checks must be carried out and confirmed by the peer reviewer before the Action can be marked as resolved, allowing you to enforce procedure in how Peer Review Actions should be completed by agents at runtime.

In Work Manager, users will then have to confirm for each item in the checklist whether they have completed it (the options are Yes, No, N/A) and they can even add a note for each check.

You can create two different levels of peer review checklists:

• 'Global' checklists - these are added to the Action type and contain a standard checklist of activities must be carried out and confirmed by the peer reviewer before the Action can be marked as resolved. Global checks will be added any time this Action type is added to a Case flow. Global peer review checks can be added/edited at Service Line level or from the Peer Review Checklist setting in the Case screen.

• 'Local' checklists - these help support 'custom' activities that take place for that specific Action that must be carried out and confirmed by the peer reviewer before the Action can be marked as resolved. Local checks will only apply to the specific Action they have been added to. Local peer review checks are added to the Peer Review Action itself from the Peer Review Checklist setting in the Case screen.

Once important feature to note is that once you've created a local checklist item, you can drag it up to LINK it to a global check, specifying whether it should run before or after a standard global check. You'll see the colour-coding denoting which global check it's linked to. If ever the order of global checks is adjusted, all the linked 'local' checks will move with it. Once you're happy with your overall checklist you can OK this and the checklist for this Action is saved.

At runtime, users reviewing the Action in Work Manager will just see a single list of the checks they must complete, with no differentiation between global and local checks. They'll have to complete all of the checks in order to mark their Action as resolved.

Adding Conditions to Bypass a Peer Review

You can also choose to automatically bypass a peer review by adding a condition to a Peer Review Action in your Case configuration. If that condition is met, the peer review part of the Action will no longer be required. This gives you more flexibility when using Peer Review Actions and allows you to avoid any unnecessary peer reviews.

To set a condition for a peer review, in your Case flow screen select the relevant Peer Review Action and, on the Peer Review tab, click the 'Bypass if' icon.

In the resulting popup, set your condition - choosing a data field (which can be standard or one of your own custom data items), then a condition and a value.

Selecting the 'Advanced' option lets you create a more complex condition with a combination of multiple criteria, adding a plus symbol between each part. You can check the validity of your expression via the external DotNetfiddle link. Once you're happy with your settings here, apply the condition.

The 'Bypass if' icon will the be highlighted, showing that a condition has been added.

Save the update to your Case and set the new version live.

Over in Work Manager, if the condition you have added is met, at runtime the activity will move straight from the manual activity onto the next Action, bypassing the peer review stage. A note will subsequently be displayed in the Actions list on the Case screen, showing that the peer review activity was not required.

You use the Case screen to create a flow of Actions which make up your business process. You can add Actions in any order, either from the existing standard menu of Actions defined, or by creating brand new Actions from within the Case screen itself.

The Steps for your Case are set as part of your initial set-up, and are not editable from the Case screen.

Once you have added an Action, you then need to set the various attributes necessary to determine how it will act at runtime. Primarily you set ‘Who does it go to’ (i.e. which Queue, and perhaps which position), ‘When is it due’ and some further general settings. The options available for you to pick here are a standardised list of ‘flavours’, shared between Case, Ticket and Action configurations.

If the Action involves checklists, you can add two different levels of Action checklists:

• 'Global' checklists - these are added to the Action type and contain a standard checklist of activities that will be added any time this Action type is added to a Case flow. See here for more details on how to configure global checklists.

• Local Checks - these are added to Actions already in a Case flow to help support 'custom' activities that take place for that specific Action. See here for more details on how to configure global checklists.

As well as making Action-level settings, you also need to set similar attributes for the overall Case.

Once you’ve finished setting these attributes, you can set the Case live.

Overview

'Approval' Actions enable an approval request flow to be added into the Case.

Often within the Case flows of business processes which are built in Enate there are points where external people (i.e. people working outside Enate - this could be business managers within your company or the relevant client company) need to sign off on activities before the process can continue. Payroll processes are good examples of such processes, where client management need to sign off on payroll reports before the process can be allowed to continue.

Enate's Approval Action is built to specifically support these scenarios in a more integrated way - to ensure that this 'approval cycle' is tightly managed and visible within the flow of activities in Enate. When an Enate Case reaches an Approval Action in a flow, things then work as follows:

• Enate uses uploaded business rules to determine the Approvers to whom approval request emails should be sent (standard email templates are available, but these can be modified to contain information sufficient for approver to review what is being requested). See dedicated section describing how your approver business rules can be uploaded into Builder.

• Once the approvers are determined, Enate sends out Approval Requests and then Waits for their response. Depending on the type of approval defined, this might send out one request after another (awaiting approval from the first) in a multilevel request, or might send the request to a group of people in one go, waiting for either one or all to approve before continuing. Note: While this is happening, the Approval Action in Work Manager sits in a state of 'Wait for more Information'

• Those approvers can then approve or decline, via a link in the email sent to them which takes them to an online form.

• Once all required Approvals have been received, the Case process can continue again*.

To use 'Approval' Actions, you need to create an 'Approval' Action type and then add the Action into your Case flows.

Creating an Approval Action Type

You can either create an Approval Action type in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating an Approval Action type from the Service Lines page adds the Action type to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Line page, select which service line you would like to add the Approval Action to and then click on the plus symbol next to the 'Process Search' box. This will bring up a drop down menu where you can select an Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the type drop down select 'Approval Action'.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively you can add an Approval Action type directly from the Case flow itself.

To do this, open a Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its type, select 'Approval Action'.

This will add the Approval Action to the Case flow.

Configuring Approval Actions

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the usual following information for an Action:

Additionally, once an Approval Action has been added to your Case flow, a new 'Approval' tab will display in the info grid.

Here you need to add the following settings that are only relevant for Approval Actions.

To create a brand new Case process, click the '+' icon in a blank Case cell on the Service Matrix screen.

You will be taken to a blank Case Screen and be met with the ‘Case Clone’ pop-up.

Here you have two options. You can either choose to clone the settings from an existing Case or you can choose to create a Case from scratch.

If you want to create a Case from scratch, simply click away from the pop-up. This will leave your new Case screen blank and you can start adding our Actions and settings as desired.

If you want to clone the settings from an existing Case, select a Case from the ‘Case Clone’ pop-up whose settings you want to copy to your new Case.

Processes from a different Case type will be highlighted in grey with a yellow border.

The 'Same Process Types Only' option lets you filter down the available processes to only show processes from the same Case type. It is disabled by default.

The 'Exclude Local Checklist' option lets you exclude local checklists from the original Case being cloned to your new Case. You can find out more about local checklists here.

You can also filter the processes by customer, contract and service. Contract options will be based the customer selection and the service options will be based on the customer and contract selections.

Once you have selected a Case, the settings from that existing Case will be cloned into your new Case's screen. From here you can adjust the Actions and settings as desired.

Overview

Enate allows the automatic sending of emails by the system.

A 'Send Email and Wait' Action type that you can add to your Case flows will automatically send out an email and wait for a reply to the email before closing and progressing to the next Action.

If you want to automatically send out an email and then immediately progress on the the next Action without waiting for a response, you should instead select a 'Send Email' Action - see here for more information on that Action type:

For detailed information on how Send Email and Wait Actions work at runtime, see the dedicated Work Manager section:

Creating a Send Email and Wait Action Type

You can either create a Send Email and Wait Action type in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating a Send Email and Wait Action type from the Service Lines page adds the Action type to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Line page, select which service line you would like to add the Send Email and Wait Action to and then click on the plus symbol next to the 'Process Search' box. This will bring up a drop down menu where you can select an Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the type drop down select 'Send Email and Wait'.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively you can add an Send Email and Wait Action type directly from the Case flow itself.

To do this, open a Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its type, select 'Send Email and Wait Action'.

This will add the Send Email and Wait Action to the Case flow.

Configuring Send Email and Wait Actions

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the usual following information for an Action:

Additionally, once a Send Email and Wait Action has been added to your Case flow, a new 'Email info' tab will display in the info grid.

Here you need to add the following settings that are only relevant for Manual, Send Email and Send Email and Wait Actions.

Overview

The Case screen is where you create and configure a flow of Actions to make up your business process.

The Case screen is made up of two main sections:

1. Flow Diagram - where you can see the Steps of the Case and configure the flow of Actions for the Case. See here for more information about designing your Case.

2. Info Section - where you configure the settings for the Case and its Actions. The Case Info tab and the Action Info tab will display by default, but other tabs might appear depending on what type of Actions you add to your flow. See here for more information about configuring your Case's settings.

Further Options in the Case Screen

If you have opened the process in view-only mode, click on the blue Edit icon in the toolbar to allow changes to be made.

This will bring up the Save and copy buttons.

You can view the status of the Case from the 'Status' dropdown.

Steps in a Case flow have already been defined as part of Case TYPE definition under the Service Line and cannot be changed from the Case screen. See here for more information on this.

Each step in the flow diagram shows you the total number of Action processes that are configured for that step.

You can adjust the height of the info section:

You can also use the ‘View’ dropdown link to change the view of the screen. You can: View the Flow only; View the Info Section only; or view both sections. Your preference will be saved when you switch between Cases and when you next log in.

The 'Version' dropdown lets you choose which version of the Process you want. By default you will see the currently draft (In Progress version), but can switch to the currently Live version and even previous now retired versions to compare process flow setup.

You can also restore a retired version of a Case process by opening the Case in edit mode, clicking on the retired version you want to restore, then clicking 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.

The 'Show Activity' button lets you see the previous activity for the Case Process. You can see who created/deleted/last edited the Case Process, so you know who to go to if you need further information. The information will be highlighted in Green if the object has been created, restored, enabled or set live; in yellow if the object has been updated; and in red if the object has been deleted, disabled or retired.

The Show in Self Service option lets you choose if you want the Case process to be available to Self Service users. 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.

Overview

You can set up Actions to display dedicated checklists of activities which must be carried out and confirmed before the Action can be marked as resolved, allowing you to enforce procedure in how Actions should be completed by Agents at runtime.

In Work Manager, users will then have to confirm for each item in the checklist whether they have completed it (the options are Yes, No, N/A) and they can even add a note for each check.

You can create two different levels of Action checklists:

• 'Global' checklists - these are added to the Action type and contain a standard checklist of activities that will be added any time this Action type is added to a Case flow. See below for more details on how to configure global checklists.

• Local Checks - these are added to Actions already in a Case flow to help support 'custom' activities that take place for that specific Action. See below for more details on how to configure global checklists.

At runtime, users processing the Action in Work Manager will just see a single list of the checks they must complete, with no differentiation between global and local checks. They'll have to complete all of the checks in order to mark their Action as resolved.

See here for more detailed information and examples about when you would use checklists on Actions.

Defining Checklists

Defining Global Checklists

Global checklists contain a standard checklist of activities that are added to an Action type and will be added any time this Action type is added to a Case flow.

You can add a global checklist either from Global Checklist section on the Service Lines screen or from within a Case screen (from the Action's checklist popup).

To add a global checklist from the Services Line screen, go to the Service Lines screen and open the Action type you want to add the global checklist to. Add the desired checks, re-order them if necessary and click to save. These checks will be added any time the Action type is used in a Case flow.

You can also add global checks from within an Action in the Case screen itself. Simply click on the checklist icon link of an Action in a Case flow, select 'Global Checklists' from the resulting pop-up and then add the desired global checks. You can re-order them as necessary. Then click to save.

Defining Local Checklists

Local checklists are added to Actions already in a Case flow to help support 'custom' activities that take place for that specific Action.

You can add a local checklist from the Action's checklist popup on the Case screen.

To do this, click on the checklist icon link of an Action in a Case flow. You'll know if there's already a checklist set to the Action as the checklist icon will be highlighted.

Clicking the icon will bring up a popup where you can create your checks. Simply click to add, then enter your description.

Once created, individual checks can be re-ordered by clicking on the drag icon then dragging and dropping. Then click to save.

Any checks created here are specific to this Action.

Once important feature to note is that once you've created a local checklist item, you can drag it up to LINK it to a global check, specifying whether it should run before or after a standard global check. You'll see the colour-coding denoting which global check it's linked to. If ever the order of global checks is adjusted, all the linked 'local' checks will move with it. Once you're happy with your overall checklist you can OK this and the checklist for this Action is saved.

Overview

‘Trigger External API’ Actions allow Enate to call out to an external system, passing a static structure containing information information about a Work Item (i.e. a Case, Action or Ticket). This Action type also includes an optional callbackURL, which allows the external system to update custom data and pass it back into Enate.

For information on how 'Trigger External API' Actions are shown at runtime, check out this Work Manager section.

The external API will be called as a POST method, and will be sent the following information:

{"Action":[ActionPacketJSONIncludingCurlyBraces],"CallBackURL":""}

The [ActionPacketJSONIncludingCurlyBraces] will be an Actionpacket, as per the response from the Enate getAction API.

Enate supports this with a 'Trigger External API' Action type that you can add to your Case flows.

For detailed information on how Trigger External APIs work at runtime, see the dedicated Work Manager section.

Creating a Trigger External API Action Type

You can either create a Trigger External API Action type in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating a Trigger External API Action type from the Service Lines section of Builder adds the Action to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Lines page select which service line you would like to add the Trigger External API Action to and then click on the plus symbol next to the 'process Search' box and then select 'Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the 'type' drop down select 'Trigger External API Action'.

You can then choose to add a global checklist to the Action. This contains a standard checklist of activities that will be added any time this Action type is added to a Case flow. See here for more information on checklists.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively, you can add a Trigger External API Action type directly from the Case flow itself.

To do this, open your desired Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its 'type', select 'Trigger External API Action'. This will add the Action to the Case flow.

Configuring a Trigger External API Action

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the usual following information for an Action:

Additionally, once a Trigger External Action has been added to your Case flow, a new 'External API' tab will display in the info grid.

If 'Response Expected Within' is left blank - further details

If you set the 'Response Expected' slider to On but no value is entered in the 'Response Expected Within' column, the Action will call the external system and wait either until the Due Date for the Action, or indefinitely.

The decision on whether the Action will wait indefinitely or not is determined based on the 'Autocomplete on Timeout' setting in the General Settings flavour set for the Action.

• If Auto-complete in General settings is set to On, the system will time the Action out when it hits the Due Date / Time.

• If Auto-complete in General settings is set to Off, the Action will wait indefinitely.

If / When the Action DOES time out at the point of reaching the Due Date, the Action will moved to a state of 'Closed' with a reason of 'No response returned'.

Note: If you have both these settings filled (i.e. a 'Response expected minutes' value AND the 'Auto-complete on Timeout' flag set), the system will act on whichever time comes first - most likely after the 'Response expected minutes' time has been reached.

Behaviour in various scenarios

There are a number of possible ways the system will behave, dependant upon how you have configured the various timeout settings AND how the external API actually responds. For detailed information on this, see the following attachment which lays out each combination of settings and behaviour, and the eventual result.

Overview

You can merge branches in your Case workflow processes to help you streamline the creation of your business Case flows.

Sometimes creating a business process can leave you with many different routes that you want to lead onto the same action depending on the criteria of the step. By using this new merge feature you will be able to choose different Actions to end in the same outcome.

Watch the following video to find out more:

How to merge branches

You can choose to merge together parallel branches or conditional branches.

To merge multiple Actions together, click on the menu of one of the Actions you want to merge and select 'Merge', then 'Add'.

In the following pop-up select the other Actions you want to merge it with from the list of Actions that are available for merging.

Then select which Action you want them to be merged into - you can either choose from an existing Action type or you can choose to create a brand new Action type for this.

The merged Action will then appear in the flow.

Specifics of merging parallel branches

If you are merging together Actions from parallel branches, the merge Action will wait for all of its the predecessor Action to complete before it can start.

Specifics of merging conditional branches

If you are merging together Actions from conditional branches, the merge Action will start when one of the conditional branches has been completed.

Creating a new type of Action

You are able to create new types of Actions within a Service Line itself by clicking on the '+' icon next to the search bar and selecting 'Action'.

When creating a new type of Action, you can enter the following information:

Creating a Global Checklist

Global Checklist items are accessed via the Service Lines screen.

These Global Checks are subsequently displayed during 'Local' checklist creation against individual Actions within the Case flow definition screen. See the Checklists on Action section for more information on Local Checklist definition.

Subsequent Editing of an Action Type

To edit an Action type’s settings, click on the Action in the Service Lines Screen and edit the information in the right hand side of the screen. Click to save these changes.

You are also able to see the activity history of your work items , by clicking on the Show Activity button. You can see when the work item was created and by who, as well as if any edits have been made to the work item, when they were made, as well as by who.

You are also able to clone a Action type by clicking on the Clone button in the edit screen. This will clone all of the Action type's settings and data apart from its name. You are able to make changes to any of the settings and data once the Action type has been cloned.

Input Links allow Cases and Tickets to be started in the Work Manager operations environment. They are automatically generated whenever a Ticket or a Case process is set live in Builder.

Input links are displayed in Work Manager:

1. In the 'Create New Work Item' dropdown

Input Links for live Case processes will always be displayed in the ‘Create New Work Item’ dropdown in Work Manager.

Live Tickets will not be shown in the ‘Create New Work Item’ dropdown

2. In the Contact Activity page

You can control whether you wish the link to appear on the Contact Activity Page by ticking or unticking the ‘Add to Contacts’ setting in the Service Matrix in Builder for that specific Ticket or Case process.

3. In work item screens

If the 'Everyone can start' option is enabled from the Service Matrix,

any Work Manager user will be able to start the process from the ‘+ Work item’ link in the work item screen, regardless of whether or not they have permission to access and edit that work item:

Creating Services

Each Service Line view shows all running Services, and all available contracts which don’t yet have a Service. To add a new Service under a Contract, click on the '+' icon at the top of the Service Matrix.

Fill in the service settings in the resulting popup.

Service Settings

The settings for Services are:

Subsequent Editing

To edit a service's settings, click on the menu icon beside the Customer name and select the Edit link. Make your desired changes in the resulting popup and click OK to save changes.

You can see what edits have been made to the customer and when, as well as when the customer was created, and even when a customer was deleted by clicking on the Show Activity button in the Edit screen.

Cloning a Service

You are also able to clone a service by clicking on the Clone button in the Add info screen. This will clone all of the service's settings apart from its name. You are able to make changes to any of the settings once the service has been cloned.

Deleting a Service

To delete a service, click on the ellipses beside the Customer, hover over the delete link and click on 'Service'.

If you delete a Service which has linked Email Routes, you will be notified of this and will need to update the respective Email Routes in order to stop them from creating more work for this Service.

Creating Customers

To add Customer companies, click on the '+' icon at the top of the Service Matrix and select 'Customer'.

Fill in the customer settings in the resulting popup.

Customer Settings

The settings for Customers are:

Subsequent Editing

To edit a Customer’s settings, click on the ellipses beside the Customer name and select the Edit link. Make your desired changes in the resulting popup and click OK to save changes.

You can see what edits have been made to the customer and when, as well as when the customer was created, and even when a customer was deleted by clicking on the Show Activity button in the Edit screen.

Cloning a Customer

You are also able to clone a customer by clicking on the Clone button in the Edit screen. This will clone all of the customer's settings apart from its name. You are able to make changes to any of the settings once the customer has been cloned.

Deleting a Customer

To delete a customer, click on the ellipses beside the Customer, hover over the delete link and click on 'Customer'.

If you delete a Customer which has linked Email Routes, you will be notified of this and will need to update the respective Email Routes in order to stop them from creating more work for this Customer.

Service Matrix

The Service Matrix displays a list of all existing Customer companies with their corresponding Live contracts and Services, split across pages by individual Service Lines.

The columns displayed for each Service Line represent the various types of Case and Ticket processes which can be created under this Service Line.

You can select which service line you want to see from the dropdown list on the top-right of the page. Your last selected service line will be saved when you return to the Service Matrix Screen from other sections in Builder, and also after you logout and log back in.

Clicking on a Case or Ticket will open a dropdown list of options. The options vary depending on the state of the Case or the Ticket. Click here for more information on the various State options.

Service Matrix Key

The key in the top right tells you the status of the Cases and Ticket processes.

For more information about these states, see below:

Sorting and Filtering

The filter function in the top-right of the screen lets you filter the Services Matrix to show specific groups of data.

You can filter by Customer, Contract and/or Service by using the dropdown list or by using the free text search function. You can add multiple Customers, Contracts and/or Services into your search filters.

Your applied filters will be saved when you return to the Service Matrix Screen from other sections in Builder, and also after you logout and log back in.

Your applied Customer and Contract filters will be saved when you switch between Service Lines in the Service Matrix, but the the Service filter will be removed.

Adding Data to the Service Matrix

The '+' icon lets you add Customers, Contracts and Services to the Service Matrix, as well as Case and Ticket types.

Overview

Enate is able to provide integration with ABBYY FlexiCapture to allow intelligent document processing to be part of your Enate processes. This means that documents such as PDFs can be scanned by ABBYY FlexiCapture both to start and to form part of your Enate processes.

When an ABBYY Action runs for a Case, documents attached to the Case can be submitted to ABBYY FlexiCapture for OCR Scanning and the processed output files will be returned and automatically attached to the Case.

Furthermore, if ABBYY FlexiCapture highlights that additional manual verification may be needed (i.e. if confidence levels in the scanned output is below threshold), the work is transferred over to an Enate agent in Work Manager to verify and adjust the data via ABBYY FlexiCapture's dedicated screen, surfaced directly within an Enate Action.

Enate supports this with an 'ABBYY OCR' Action type that you can add to your Case flows.

For detailed information on how ABBYY Actions work at runtime, see the dedicated Work Manager section.

Creating an ABBYY Action Type

To create an ABBYY FlexiCapture Action, you first need to set up an ABBYY FlexiCapture connection.

See this article for more information about how to set up an ABBYY FlexiCapture connection:

Once you have successfully set up an ABBYY connection, you then need to create an ABBYY FlexiCapture Action type.

You can either do this in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating an ABBYY FlexiCapture Action type from the Service Lines section of Builder adds the Action to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Lines page select, which service line you would like to add the ABBYY Action to and then click on the plus symbol next to the 'Process Search' box. This will bring up a drop down menu where you can select an Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the 'type' drop down select 'ABBYY OCR'.

You can then choose to add a global checklist to your ABBYY FlexiCapture Action. This contains a standard checklist of activities that will be added any time this Action type is added to a Case flow. See here for more information on checklists.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively, you can add an ABBYY FlexiCapture Action type directly from the Case flow itself.

To do this, open your desired Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its 'type', select 'ABBYY OCR'. This will add the ABBYY FlexiCapture Action to the Case flow.

Configuring an ABBYY Action

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the following information:

Additionally, once an ABBYY Action has been added to your Case flow, a new 'ABBYY FlexiCapture' tab will display in the info grid.

Here you need to add the following settings that are only relevant for ABBYY Actions:

Your ABBYY FlexiCapture Action is now ready to be used in your Case flows.

See below some formatting directions to help when building conditions within your Case flows.

Using a Date / Time in a Condition

Format to enter in value column: new DateTime(yyyy,MM,dd,hh,mm,s)

EX: new DateTime(2020,05,30,12,00,00)

Using a Date in a Condition

Format to enter in value column: new DateTime(yyyy,MM,dd)

EX: new DateTime(2020,05,26)

Using Short Text in a Condition

Format to enter in value column: “String”

EX: “To test Short text 1”

Using Long Text in a Condition

Format to enter in value column: “String”

EX: "To test long text 1"

Using a Decimal Number in a Condition

Format to enter in value column: x.yM

EX: 1.2M

Using a Whole Number in a Condition

Format to enter in value column: X

EX: 10

Using a Boolean (Checkbox) in a Condition

Format to enter in value column: true/false

EX: true

Using a Multi-level List in a Condition

Format to enter in value column: “Level1.Level2.Level3”

EX: "CONTACT NO.HOUSE.1234567"

Using a List in a Condition

Format to enter in value column: “String”

EX: "Blackberry"

Using an Email in a Condition

Format to enter in value column: “Email Address”

EX: "jhon@gmail.com"

Creating Contracts

To add customer Contracts, click on the '+' icon at the top of the Service Matrix and select 'Contract'.

Fill in the Contract settings in the resulting popup.

Contract Settings

The settings for Contracts are:

Subsequent Editing

To edit a contract's settings, click on the ellipses beside the Customer name and select the Edit link. Make your desired changes in the resulting popup and click OK to save changes.

Editing of Service Provider of Existing Contracts

In Builder you can edit the Service Provider of existing Contracts.

Further aspects to be aware of include:

• Data is retrospectively changed for all Work Items, both running and complete. Depending on the number of Work Items in the system this may take a short amount of time to update in all views and reports.

• The Service Provider drop down is only shown when creating or editing Contracts if there are multiple Supplier companies in the system.

You can see what edits have been made to the customer and when, as well as when the customer was created, and even when a customer was deleted by clicking on the Show Activity button in the Edit screen.

You are also able to clone a contract by clicking on the Clone button in the Edit screen. This will clone all of the contract's settings apart from its name. You are able to make changes to any of the settings once the contract has been cloned.

Deleting a Contract

To delete a contract, click on the ellipses beside the Customer, hover over the delete link and click on 'Contract'.

If you delete a Contract which has linked Email Routes, you will be notified of this and will need to update the respective Email Routes in order to stop them from creating more work for this Contract.

Enate allows you to configure mailbox integrations so that incoming emails can generate new work items / be attached to existing work items and allow the system / agents to send outgoing emails via Enate. You can access this section, along with other email configurations, from the Email link in the Builder toolbar.

Here you can configure:

• Email Connectors – click for more information about email connectors.

• Email Routes – where to route incoming emails, i.e. referencing the email addresses in the Connectors you have created, you can specify which Tickets or Cases should route brand new emails into a certain inbox. Click for more information about email routes.

This approach allows you to set up and maintain how your Tickets and Cases run in conjunction with email servers without having to modify the actual Ticket and Case processes all the time.

Adding an Email Connector

To add a new email connector click on the ‘+’ icon at the top right of the Email Connectors page, select 'Email Connector' and fill out the details in the resulting popup.

The attributes to configure are:

Setting a Fallback Email Route

You must also set a fallback email route 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.

When setting a fallback route you must 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.

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.

Behaviour After Upgrade to v2022.5

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:

Auto-Selection of Fallback Routes during Upgrade

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.

How Fallback Routes Subsequently Display in 'Routes' Section

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

Testing a Connector & Setting it Live

Once you have configured the required information you must then test the connection. To do this, click on the 'Test Connection' button.

Once the connection has been tested successfully, you can then enable the connector by switching on the 'Enable' toggle.

Editing an Email Connector

You can edit an email connector by clicking on the ellipsis and choosing 'Edit'.

When editing an email connector, you are also able to see its activity history by clicking on the Show Activity button. You can see when the email connector was created and by who, as well as if any edits have been made to the email connector, when they were made and by who.

Default Email Connector for Outgoing emails

The system has a default outgoing email Connector called ‘System Default SMTP Gateway’ for standard system activities e.g. User Welcome emails etc.

Overview

Once you have some email connectors defined, you can reference them in email routing to specify where emails coming into each mailbox should be routed by Enate (i.e. which work items it should start).

The Email Routes page is where you can create new email routes and manage your existing ones.

Email routes are grouped by the email connector to which they are associated. These groups can be expanded and collapsed, making larger bodies of data easier to work with.

Filtering email routes

At header level, you can search to filter down your view to just one Connector:

Search by Connector details within each section

You can search for a route at a connector-level, based on its email address, process and/or Ticket category (if relevant).

Folder Filter for Graph API Routes

For Graph API routes, you have the option to view folders as an additional filter at the top of the screen.

Adding an Email Route

Watch this video to find out how to set up an Email Route:

More information about the attributes to configure when creating a new email route:

When editing an email route, you are also able to see its activity history by clicking on the Show Activity button. You can see when the email route was created and by who, as well as if any edits have been made to the email route, when they were made and by who.

Quick-create Routes from Connector section shortcut

Additionally, as a useful shortcut you have to ability to add a new email route directly within a specific email connector itself - clicking on the '+' icon next to a connector will bring up the 'Create an Email Route' pop-up with the email connector name already filled it.

Adding Email Routing Rules

You can add routing rules to an email route to provide a more fine-tuned way of determining where an incoming email gets routed to (and therefore what kind of work item gets created). Watch this video to find out more:

Routing rules can be based on the information of the incoming email including:

1. Important Flag on Email - if the email has been flagged as 'important'

2. Has Attachments of Type... - if the email has an attachment of a certain type - list of file extensions separated by a semi-colon e.g. .pdf; .docx

3. Key Words in the Subject Line - list of key words in the email subject line separated by semi-colons e.g. urgent; support; reset

6. Sender's company name includes - lets you direct incoming mails based on the company the email sender belongs to. This stops you having to create multiple variations of slightly different email domain-based routings for your larger clients. Select the sender's company name from the dropdown. You are able to add multiple companies. Any emails arriving from email addresses belonging to the companies you have selected will start the process set in the email route.

You can add multiple routing rules to an email route:​

Email Routing by Domain

You can route emails based on a particular email domain by adding a '*' before the domain:

Ordering Email Routes

You can easily adjust the ordering of the routes for a connector by dragging and dropping to the desired location. When deciding on the order in which to run multiple related routings, you should place the most specific rules first, and set more generic ‘fallback’ routings last.

Additional notes regarding email route reordering:

• Email routes cannot be dragged outside of their respective group.

• Reordering via the routes grid is only possible with the necessary permissions.

• Email route re-ordering will be blocked unless the route grid is sorted by Priority Order: ascending (as this makes the reordering interaction less confusing). When the route grid is not sorted by Priority Order: ascending, a message will show to alert you.

Quick Reordering of Email Routing

For connectors with extremely large numbers of routings, you may wish to manually set the order number directly (a useful alternative to having to drag routings hundreds of places up and down some of the larger lists). To do this, simply right-click the desired row and click the resulting tooltip:

Fallback Email Routes

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 email routes 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

Email Route configuration limitations

When configuring email routes, if a sender is an unknown user or a new contact, a route that contains a company filter cannot match. This can lead to emails possibly being sent down the wrong route. To help avoid this, do not combine the following configurations:

• Combination One 1. Auto create contacts 2. Contacts locally scoped 3. One or more email routes with a company filter

• Combination Two 1. Contacts Locally scoped 2. One or more email routes with a global company filter

Systems set up in this way may result in unpredictable and inconsistent routing of mails and should be avoided. These combinations of setup are not supported.

Overview

The Document Extraction component automatically extracts the relevant data from files attached to incoming emails so that this data can be used in further processing of the work item, saving your agents time and effort. This also means that documents such as PDFs can be scanned and used both to start Cases in Enate and to form part of the ongoing process's activities.

When a Document Extraction Action runs for a Case, documents attached to the Case can be submitted to your desired technology for scanning and the processed output files will be returned and automatically attached to the Case.

If at any point the technology you're using is not confident enough of the results, based on a confidence threshold that you can set, Enate will instantly transfer the work to an agent in Work Manager to look over and verify, giving you that 'human in the loop' support.

Enate supports this with an 'IDP Data Extraction' Action type that you can add to your Case flows. You'll need to before you can use IDP Data Extraction Actions in your flows.

For detailed information on how IDP Data Extraction Actions work at runtime, see the dedicated section.

Creating an IDP Data Extraction Action Type

To create an IDP Data Extraction Action, you first need to have activated the Data Extraction component in Enate Marketplace. See for more information.

You'll then need to set up your Case flow to support the Document Extraction component. This involves adding an 'IDP Data Extraction' Action in Enate Builder to use in your desired Case flows.

You can either add an existing one from the Actions list if one has already been created, or you can create a brand new one.

IDP Data Extraction Actions can be created in the same way any other Action is created in Enate: either from the Service Line page, or directly from within your Case flow.

To create an IDP Data Extraction Action from the Service Line page, select to create a new Action under the desired service line, give the action a name and a description and choose approval action from the type drop down.

To create an IDP Document Extraction Action directly from the Case flow itself, open a Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its type, select 'Approval'. When you click 'OK, the Action will be created and added to the Case flow.

Once you have added your approval action to your flow, you will then need to fill out its settings.

On the Action Info tab you will need to set when it's due and set an Allocation rule.

There's also general settings for the Action too, and ability to set a custom card, again only really for use in the unlikely event that someone needs to intervene and view the action in Work Manager.

Next, go to the IDP Document Extraction tab to define the settings which specifically relate to the approval activities.

You'll need to fill in the Extraction Model - this is the ID of the model you want to use for that process.

You'll also need to fill in the input and output tags. The input tag is the tag that the file/document must be tagged with in Work Manager in order to be eligible for document extraction processing and output tags. The output tag is the tag that will be assigned to the file/document in Work Manager once the document extraction process has completed.

Once you have filled in the above settings details, set the Case live.

Configuring an IDP Data Extraction Action

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the following information:

Additionally, once an IDP Document Extraction Action has been added to your Case flow, a new 'IDP Data Extraction' tab will display in the info grid.

Here you need to add the following settings that are only relevant for IDP Document Extraction Actions:

Your IDP Document Extraction Action is now ready to be used in your Case flows.

When using conditionality in your Case flows, you can use a number of types of system data as part of your condition, for example standard system work item fields and custom data fields.

We have now added the ability to use the results of individual checklist items, both global and local, in your conditions, letting you choose alternate routes depending on how a check has gone.

Watch this video to see how that can be done, or read below for more specifics and details:

Clicking on the dropdown will reveal the Actions that have checklists to choose from. They will be displayed in the order in which the Actions appear in the flow. Clicking on an Action will show the checks that you can choose to base your condition on, displayed in order in which they appear on the checklist.

You can only use the 'Equals' and 'Not Equals' conditions for conditions based on the results of a check in an Action's checklist, just as you would short text data fields.

The values you can create conditions for against a checklist item are "Yes", "No", and "NA" for Not Applicable. Be aware that these values are case sensitive and should be entered in the value field exactly as above within double quotes.

As standard, make sure to create an 'else' branch, to handle the flow when you're conditions are not met. At runtime, if the condition is not met, the system will execute the 'else' branch.

If you're using the advanced option to build a more complex expression, checklist items can also be incorporated here - once you've picked them from the dropdown list they'll be added into your expression with a unique identifying GUID.

Once you're happy with your condition settings, click 'validate' to ensure they'll work at runtime, then 'OK' to apply the condition to the Case flow.

Overview

You also have the ability to end an individual Case early (if it is no longer needed) when you're setting up a Case process. This mean that at runtime the Case doesn't have to always continue until the end of the flow in order to close.

This is useful in circumstances where it is no longer relevant to complete the Case, for example it's no longer relevant to complete a New Starter Induction Case if the person is no longer joining the company.

At runtime in Work Manager, once an 'End Case' Action is reached in a process, no further Actions in the Case flow are triggered and the Case will Close.

Configuring an End Case Action

To add this ability into your Case flow processes, you just need to add the new 'End Case' Action type into the relevant place in your Case process flow in Builder. Multiple 'End Case' Actions can be added to a Case flow, however note that:

• they must be added at the end of a branch AND

• no other Actions can be added after it in the branch's flow.

You should use End Case Actions in conjunction with a condition in your flow configuration. Watch this video for more information about how to configure an End Case Action:

Work Manager Impact

When a Case closes due to it reaching an End Case Action, the Case will display as being Closed with a reason of 'All relevant Actions completed'.

If a feedback window is configured for the Case, the Case will instead move to a Resolved state and will follow standard system logic i.e. it will sit in this status for a defined period of time during which the service recipient may respond and the Case may be reopened, either automatically upon receipt of a new incoming email or feedback within the time period, or manually by the agent.

If the feedback window has completed without any further response, or if the Case does not have a feedback window, the Case will move to a state of fully 'Closed'.

See this article for more information about how Cases are processed in Enate:

Protocol Support

Enate currently only supports SMTP/SMTPS for sending email. GraphAPI is currently only available for incoming email.

Enate Message Handling for Outgoing Email

Internally, Enate matches on the outgoing "From" to determine what email connector configured as either ‘Outgoing’ or ‘Both’ should be used to send a specific message. If no specific email connectors match the "From" address then Enate will fall back to using the System Default Gateway for sending email.

The unmonitored email address which is used as the From address on some automated outgoing emails such as password reset mails (and which you can set in the General Settings section of Builder) functions in the same way as the above configured From addresses. If the System Default Gateway is disabled, you must provide a valid email address for this unmonitored email which has been configured as an outbound email connector.

Common SMTP Configurations

Outgoing email can be configured in several different ways in Enate depending on the preferences of your mail server teams.

As with incoming email, Enate requires an external DNS name and publicly trusted certificate be configured with SMTP.

The port that Enate connects to SMTP on is configurable within Builder on a per connector basis and so the firewall requirements are dependent on the mail server teams and their configuration of these protocols. Typically, either port 25 for SMTP or ports 465 or 587 for SMTPS are used.

Instance-Wide SMTP Gateway

An SMTP gateway can be created with the ability to relay all email sent via it. This can be restricted with a username/password combination to avoid creating an open relay that may be subject to abuse. This can then be configured as the default SMTP/outgoing connector within Enate Builder.

This simplifies ongoing email configurations allowing new incoming email addresses to be added without needing to adjust permissions for sending.

Instance-Wide with 'Send As' Permissions

Similar to the above, a gateway can be supplied where a user account with Send As permissions on every account/Email address used within Enate can send email.

For example, an enate.production@example.com account could be created with Send As permissions on enate.sales@example.com, enate.finance@example.com and enate.accounting@example.com. This enate.production@example.com could then be configured instance-wide within Enate Builder.

This increases the configuration complexity and also requires IT or mail servers to add new addresses on an ongoing basis whenever these are required within Enate.

Per-Email Connector SMTP Server Settings

When configuring email connectors in Enate, you can specify either Incoming, Outgoing or Both for the direction.

These settings allow you to configure outgoing email to use connector specific SMTP values. No additional credentials can be specified here and so the POP3/IMAP4 credentials specified on the email connector in Enate must have Send As permissions on the configured SMTP From Address value.

This configuration typically only works where the incoming POP3/IMAP4 address is also the address that will be used to send replies, for example if customers are emailing enate.sales@example.com and the reply will also come from enate.sales@example.com. If this is not the case then this configuration leads to having to manage multiple sets of permissions across different accounts to allow Send As permissions to cover all addresses used in Enate.

When new emails arrive into Enate, the system analyses the email to determine whether it’s a brand new request or related to an existing one, and then determines how to proceed.

The system can be set up to analyse incoming emails in three different modes to try to match it with an existing work item (the selection of which mode to use is made in the 'Work Item 'Plus Addressing'' section of Builder's System Settings). Options are as follows:

• Plus Addressing OFF - Plus Addressing is completely disabled and emails are matched using the standard email processing rules only.

• Mixed Mode - Plus Addressing is enabled and emails are matched using both plus addressing AND the standard processing rules standard email processing rules.

• Plus Addressing Only - Plus Addressing is enabled and emails are matched using plus addressing ONLY.

See the section for more detailed information on each of these modes and how the system operates in each case.

Using one of these modes, the system will attempt to match the email with an existing work item. If it finds a match, then depending on the state that work item is in, it will behave as follows:

Sending an Incoming Email to an existing running work item

If the system finds a match to an existing Ticket, Case or Action that is in a state of DRAFT, TO DO or IN PROGRESS, the system will:

• append the email to the work item

• mark the work item with ‘new information received’

The same applies to auto-generated emails that are matched to an existing work item in a state of DRAFT, TO DO or IN PROGRESS. Please see the for more information on how the system detects auto-generated emails.

Sending an Incoming Email to a work item in a state of Waiting

If an incoming email is matched to an existing work item that is in a state of WAITING, the system will:

• append the email to the work item

• mark the work item with ‘new information received’

In addition, if the Wait type is 'Waiting for more information, the system will:

• change the state of the work item from WAITING to TO DO

• As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’

• If the work item is an Action and both the Action and its parent Case are in a state of WAITING with a wait type of Waiting for more information, the state of the parent Case will change to IN PROGRESS

Sending an Incoming Email to a Resolved Work Item (Case & Ticket)

If an incoming email is matched to an existing work item that is in a state of RESOLVED (note that only Cases and Tickets can be in a state of RESOLVED), the system will:

• Append the email to the work item

• Reopen the work item and set it back to TO DO

• As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’.

Sending an Incoming Email to a Closed Work Item

If an incoming email is matched to an existing work item that is in a state of CLOSED, the system may take various courses of action depending upon the type of work item:

• The system will firstly ‘go up’ the work item chain to look for a parent work item e.g.

  • if the email is matched to an Action that is CLOSED, the system will see if the Action’s parent Case is still open.

  • if the email is matched to a Case that is CLOSED, the system will see if the Case has a parent Case or Ticket that is still open.

  • if the email is matched to a Ticket that is CLOSED, the system will see if the Ticket has a parent Ticket that is still open.

• If the system does find a parent work item that is still open, the system will then apply the rest of the email processing logic to the parent work item (i.e. all of the logic in the above sections on running work items).

• If the email is sent to a closed child split ticket, the system creates a new work item for the email.

If unable to match an incoming email to an existing work item

If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.

Further specifics

• Split Ticket – if an incoming email is matched to a split Ticket – either the original Ticket that was split or one of the child Tickets it was split into – the email will be appended to each of the CHILD Tickets. The system will then apply the rest of the email processing logic to each of the child Tickets independently.

• Merged Ticket - if an incoming email is matched to a merged Ticket – either one of the original Tickets that were merged or the ‘target’ Ticket that they were merged into – the email will be appended to the ‘target’ Ticket. The system will then apply the rest of the email processing logic to the ‘target’ Ticket.

• Ticket converted into a Case – if an incoming email is matched to a Ticket that was Resolved by being converted into a Case, the email will be appended to the Case. The system will then apply the rest of the email processing logic to the Case.

Auto-Generated Emails Detection Logic

The system detects auto-generated emails by one-or more of the following:

• A « x-autoreply » header exists

• A « x-autorespond » header exists

• A « auto-submitted » header exists and the value is either « auto-generated » or « auto-replied »

• A « content-type » header exists and the value is either « multipart/report » or « delivery-status »

• The ReturnPath header exists and has a value of « <> » or « <<>> »

Important Note - Incoming Emails from your Enate instance will be ignored

Before processing any emails Enate will check to see if it sent it. Every email has a unique identifier which should not change. Enate stores the unique identifiers of emails that it has sent and uses these to perform this check.

This Enate behaviour is to avoid duplicate processing of items which Enate may well have already processed before the outgoing email has been sent, for example (but not limited to) auto-appending of mails to linked work items via Plus Addressing logic.

How does Enate decide which processes to start when it receives an Email

When deciding which process to start, Enate looks at all the routes for the connector for the email address under consideration (NB* This means that if you spread routes across connectors, you’ll get odd behaviour!).

Enate then looks at each route in the order you have defined, starting at the top (1) checking for the criteria you have added. If all the criteria match then the route is used, if any of the criteria don’t match, Enate will move onto the next route.

The last route is a catch all (fallback) route, however if the email has been sent to an alias, then the catch all route will not match and the email will be made available for processing in ‘Unprocessed View’

Emails received by BCC

If the email has been sent to Enate using Blind Carbon Copy (BCC) then by design Enate is not able to see which email address the email has been sent To (If Enate could see the address list it wouldn’t be ‘blind’). This causes all routes to fail to match.

Handling of Incoming Reply emails

A specific sceario to handle for incoming email processing is where someone CC'd on a mail sent into enate replies to that email. Enate recognizes the situation and will attach that mail to the original work item, rather than creating a brand new work item.

The technical specifics of this are as follows: Improved 'InReplyTo' logic has been added for processing incoming mails. We now validate if the 'InReplyTo' field of the incoming email aligns with the Message-ID of a prior email. When matched, the email/communication is appended to the relevant work item. In short: if we can tell that a mail has been sent in reply to a mail we already know about, we direct that new mail to the previous mail's work item.

How does Enate deal with Out of Office emails?

Enate deals with incoming 'Out of Office' emails in two ways:

1. If the 'Out of Office' email is generated in response to receiving an email written by a user in Enate, Enate will append the 'Out of Office' email to the work item and mark the work item with ‘new information received’. See below for further specifics.

2. If the ‘Out of Office’ email is sent in response to an auto-generated email from Enate (e.g. acknowledgement of Ticket creation), the 'Out of Office' email will NOT be appended to the work item and the work item will not be marked with ‘new information received’ - it will effectively be ignored.

Expanding on the logic for situation 1 above where an 'Out of Office' email is generated in response to receiving an email written by a user in Enate...

Incoming Out of Office Emails matched to an existing running work item

If the incoming 'Out of Office' email is matched to an existing Ticket, Case or Action that is in a state of DRAFT, TO DO or IN PROGRESS, the system will:

• append the email to the work item

• mark the work item with ‘new information received’

Note: This logic above applies to all auto-generated incoming emails that are matched to an existing work item in a state of DRAFT, TO DO or IN PROGRESS (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in these states). Please see this section for more information on how the system detects auto-generated emails.

Incoming Out of Office Emails matched to a work item in a state of Waiting

If the incoming 'Out of Office' email is matched to an existing work item that is in a state of WAITING, the system will:

• append the email to the work item

• mark the work item with ‘new information received’

In addition, if the Wait type is 'Waiting for more information', the system will:

• change the state of the work item from WAITING to TO DO

• As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’

• If the work item is an Action and both the Action and its parent Case are in a state of WAITING with a wait type of Waiting for more information, the state of the parent Case will change to IN PROGRESS

The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of Waiting or Waiting for more Information (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.

Incoming Out of Office Emails matched to a Resolved Work Item (Case & Ticket)

If the incoming 'Out of Office' email is matched to an existing work item that is in a state of RESOLVED (note that only Cases and Tickets can be in a state of RESOLVED), the system will:

• Append the email to the work item

• Reopen the work item and set it back to TO DO

• As a result of the change in state to TO DO, a Queue and assignee will be set to the work item and it will move back to the responsible agent’s Enate Inbox, marked with ‘new information received’.

The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of RESOLVED (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.

Incoming Out of Office Emails matched to a Closed Work Item

If the incoming 'Out of Office' email is matched to an existing work item that is in a state of CLOSED, the system may take various courses of action depending upon the type of work item:

• The system will firstly ‘go up’ the work item chain to look for a parent work item e.g.

  • if the email is matched to an Action that is CLOSED, the system will see if the Action’s parent Case is still open.

  • if the email is matched to a Case that is CLOSED, the system will see if the Case has a parent Case or Ticket that is still open.

  • if the email is matched to a Ticket that is CLOSED, the system will see if the Ticket has a parent Ticket that is still open.

• If the system does find a parent work item that is still open, the system will then apply the rest of the email processing logic to the parent work item (i.e. all of the logic in the above sections on running work items).

• If the system cannot find a parent work item that is still open, the incoming email will NOT be appended to the already closed work item. It will instead create a new work item following the rules below for what happens when the system is unable to match an email to an existing work item.

The same rules apply to other auto-generated incoming emails that are matched to an existing work item in a state of CLOSED (i.e. incoming Out of Office emails are treated in exactly the same was as other incoming auto-generated emails in this state). Please see this section for more information on how the system detects auto-generated emails.

If unable to match an incoming out of office email to an existing work item

If no information can be identified to link the incoming 'Out of Office' email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules.

If a Ticket has been created, even if the email route settings specified in Builder have the ‘send response’ option set to ‘on’, a confirmation email will NOT be automatically sent back out to the to the email address that the 'Out of Office' email originated from as the 'Disable Automated Emails' option will be automatically switched on.

To help users understand how using wildcard routes will impact BCC emails the table below shows the possible scenarios that can occur:

This section details what happens when subsequent response emails are sent into Enate after an initial work item has been created. These could be sent by the original sender, or by other people included in the original email ('cc' or 'To' recipients) who may have no link to the Enate system.

Each sample scenario begins with..

1. In 'Traditional' mode (Plus Addressing Mode OFF)

A number of different scenarios are detailed in the table further below, however there is a fairly standard overall logic of how subsequent incoming emails are treated by Enate when running in 'Traditional' mode, if you need a 'rule of thumb'..

• Standard - If you respond to a mail that includes a connector email address, the mail will get appended to the work item that connector created.

• Add New Connector - If you add a new connector email address into a response email, a new work item will be created, linked to the initial work item. If the original connector email address is still in the email addresses, the email will also append to that original work item."

• BCC - If the connector email address is only a BCC, the email will sit in 'unhandled emails', unless you have a fallback rule set up which routes mails with that 'from' address.

• Split - If a ticket is split and you respond to the original ticket, it will get appended to all of the resulting split tickets.

• Merge - If a ticket gets merged and you respond to the original ticket, it will get appended to the remaining merged ticket.

• Case - If a ticket gets promoted to a Case and you respond to the original ticket, it will get appended to the Case.

Scenarios - Traditional Mode

Case-Sensitivity

‌Please be aware that C# Script methods and properties are case-sensitive (e.g. “SubString” would throw an error, whereas “Substring” would work). Comparisons of text fields are also case-sensitive, so an expression of “customerName = ‘My Test Company’ would not match if the company name was “My test company”.‌‌

Enate Custom Data Type vs .Net Type

‌It is important to understand the .Net Type of the field or variable you are using to understand the properties and methods that are available:

What are Actions?

Actions are the constituent parts of a Case, i.e. a Case is made up of a flow of Actions.

The Actions that you can add to a Case flow come from a standard menu of Actions, but can be added in any order.

You can add a variety of types of Actions - see below for more details.

Actions can be manual (i.e. can be carried out by humans and bots) or the can be automatic, e.g. auto sending an email.

You can choose to add a set of instructions to an Action, often a checklist of activities, to track progress within the Action.

All the manual Actions that are added to the process flow are shown under [Action Info] tab, and you can configure their standard attributes there. Additionally, specific types of Action (e.g. Email and Peer Review) Actions have further attributes which are displayed in subsequent tabs in the same location. These will only display once you add an Action of that type to your flow.

What types of Action can I add?

Depending on which Action types have been creating in your system, you can add the following types of Action:

• ABBYY FlexiCapture Actions - these Actions provide integration with ABBYY FlexiCapture

• Approval Actions - these Actions enable the creation of approval request flows.

• Manual Actions - these Actions are carried out by humans or bots

• Manual with Peer Review Actions - these Actions allow different members of a team to crosscheck each other's work. They involve two parts: the first part is the "doing" of the Action by one user, the second part involves reviewing to check if the Action was completed correctly - this review is done by a different user.

• Send Email Actions - these Actions involve the user sending out an email

• Send Email and Wait Actions - these Actions involve the user sending an email and waiting for a response.

• Start Case Actions - these Actions

• Trigger External API Actions - these Actions are used when you need to automatically call out to another system, passing data to it and potentially getting the external system to pass updated custom data back into Enate.

• Wait for Sub Cases to Complete Actions - these Actions wait for a specific Sub-Case to reach completion before allowing the Case to move on to the next Action.

Action types can be configured in the Service Lines page, see this article for more details, or directly from within a Case screen itself.

How do I add Actions to a Case?

If you need to add additional Actions to your Case, you can do this by:

1. Adding an Action from a step

2. Adding an Action from an existing Action

3. Adding an ad-hoc Action

Adding Actions from a step

Clicking on the menu icon on the right of a Step will give you the option to:

• Add a Condition (click here for more details)

• Add an Action in series

• Add a parallel Action

You then need to choose which Action you want to add to the flow

Adding Actions from an existing Action

Clicking on the menu icon on the right of an Action will give you the option to:

• Delete the Action

• Cut / copy / paste the Action

• Move the Action up or down within the Step flow

• Add further Actions, either before, after or parallel to the selected Action

When adding an Action from another Action, you can choose to add an Action before, after or in parallel to the selected Action.

How do I edit a Case Flow

Once you have added an Action, clicking on the menu icon on the right of it in the flow will give you the option to:

• Add further Actions, either before, after or parallel to the selected Action

• Rearrange the order of Actions by moving the Action up or down within the same Step

• Merge multiple Actions - adding a new merged Action or editing an existing merged Action

• Cut / copy / paste the Action

• Delete the Action

Copy/Paste Actions

You can also cut, copy and paste Actions within a Case Flow diagram.

Selecting the Action to be cut/copied and pasted in the Flow Diagram will highlight the Action in the Grid below as well.

How do I configure an Action's settings?

Clicking on an Action in the Case flow will open the Action Info tab in the info grid and highlight that particular Action in the grid.

Here you can the configure the following settings for that Action:

Different types of Action might require additional settings. These can be added in the additional tabs that will appear when these Actions are added to the flow. See here for more information.

Copy/Paste Data

In every tab in the Info Section apart from the Case tab, you can copy and paste data to make configuring attributes quicker and easier.

You can select data from multiple cells and paste that data into selected destination cells.

If you want to copy more that one cell from multiple columns, you must make sure to copy the same number of cells from each column:

If the number of cells you select to paste data to is more than the number of cells you have copied, the data you have copied will repeat itself to fill the highlighted cells.

If the number of cells you select to paste data in is less than the number of cells you have copied, you will only paste data to fill the highlighted cells i.e. if you copy the data from 4 cells but select to paste that data into 3 cells, then only the data from the first 3 cells you copied will be pasted.

If you select to paste data into multiple places, the data that is pasted will begin from the start of the first cell you copied.

The data from the first cell you select will be pasted first:

Overview

When new emails arrive into Enate, the system analyses the email to determine whether it’s a brand new request or related to an existing one, and then determines how to proceed.

The options for email processing are as follows:

• Plus Addressing OFF - Plus Addressing is completely disabled and emails are matched using the standard email processing rules only (i.e. those not used in Plus Addressing).

• Mixed Mode - Plus Addressing is enabled and emails are matched using both plus addressing AND the standard processing rules standard email processing rules.

• Plus Addressing Only - Plus Addressing is enabled and emails are matched using plus addressing ONLY.

The setting for this is made in the 'Work Item 'Plus Addressing'' section of Builder's System Settings.

Which mode is best for me?

Depending on how your email server is configured / what changes you may have recently made, here is our recommendations for which of these modes to use:

• If your email server is configured to support plus addressing, we recommend that you use Plus Addressing Only.

• If you are transitioning from Plus Addressing OFF mode to include plus addressing, we recommend that you use Mixed mode for a short amount of time to ease the transition before switching to Plus Addressing Only mode.

• If your email server is not configured to support plus addressing, you should use Plus Addressing OFF mode.

What is Plus Addressing & why is it useful in Enate?

Plus Addressing is an industry-defined feature which allows the automatic addition of information into an email address when a mail is being composed. Systems can then subsequently use this additional information if they know to look for it within the email addresses, while still ensuring that the mail gets to its intended recipients. In Enate, we make use of Plus Addressing by automatically adding the reference number of a Case, Action or Ticket (e.g. '101203-T') into the email address of any emails that we know should be being subsequently shared with that work item.

Adding this extra information into the email addresses of mails relating to work items allows us to run an additional layer of processing logic for any response emails which come back in as responses from them. The logic is fairly simple: If a work item reference number is recognized as part of any of an email's target mail addresses, that mail is shared with that work item.

Doing this massively reduces the chances of creating unnecessary work items when sending emails back and forth - particularly useful when there are multiple separate work items being actioned across multiple separate teams in Enate to deal with larger queries.

Example

If an Agent is emailing out a reply to a query that has arrived into the mailbox 'info@enate.io', upon sending the emailback out, Enate will auto-populate the From email address with a plus sign (+) followed by the reference number of the work item as a tag, so the From email address coming out of Enate will look something like this: 'info+123-T@enate.io'. The underlying structure of this is: [email connector address][+EnateRef]@[email domain].

Similarly, if the person sending the email out from Enate includes other Enate email addresses (e.g. they're copying in other internal departments) where there might also be a linked work item the email could be shared to, the system will allow the sender to share their mail with these other departments - it does this by adding in further work item references to the other departments' email addresses.

Check out this article showing how Working Between Teams is improved by this approach.

Plus Addressing OFF Mode

How does Enate match an incoming email in Plus Addressing OFF mode?

In Plus Addressing OFF mode Plus Addressing is not used, so incoming emails will be matched using the standard email processing rules. Plus Addressing OFF mode will match with a single work item. Plus Addressing matches with multiple relevant work items, if they exist.

The system will look at the following list of criteria in order and if it finds a match, it will stop searching (i.e. first one wins). The order this runs in is as follows:

1) Header ‘in-reply-to’ value – the ‘in reply to’ value in the header of the email. This value has the following structure:

<‘Unique email GUID’.’work item GUID’@‘Enate server that sent the email’.enate>

e.g. <d23a9d57-6006-4ab7-a412-8ca8ece2f3aa.2b8586bb-ef95-4020-9cf8-ed56a059b47e@SendingServerName.enate>

2) Unique identifier in email message body - If the incoming email has been sent as a response to an email which was sent out from Enate, it will likely contain a unique identifier tag as part of the email body text.

3) Work item reference in email subject

4) Work item reference in email message body

What happens when a match cannot be found? - New Work Item created

If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.

When should I use Plus Addressing OFF mode?

If your email server is not configured to support plus addressing, you should use Plus Addressing OFF mode.

Mixed Mode

How does Enate match an incoming email in Mixed mode?

In mixed mode, Plus Addressing is enabled and emails are matched using BOTH:

• Plus Addressing (to potentially multiple work items) AND

• The standard email processing rules (which stops after it matches with a single work item). See this section for an explanation of the standard email processing rules.

What happens when a match cannot be found?

If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.

When should I use Mixed mode?

If your email server is configured to support plus addressing and you are transitioning from Plus Addressing OFF mode to plus addressing, we recommend that you use mixed mode for a temporary period to ease the transition before switching to Plus Addressing Only mode.

This is because any emails sent out before plus addressing was introduced will NOT contain plus Addressing information in the email addresses of any response emails coming back into the system. If you were running Plus Addressing Only mode, such emails would not be able to find a match and so would lead to undesirable creation of new work items, rather than matching to an existing work item.

Once you are comfortable that there are no / very few work items in your system which are still open but which started before Plus Addressing was enabled, you can then consider if you wish to move to Plus Addressing Only mode.

Plus Addressing Only Mode

How does Enate match an incoming email in Plus Addressing Only mode?

In Plus Addressing Only mode, Plus Addressing is enabled and emails are matched ONLY through Plus Addressing. This means that when new emails arrive into Enate, the system analyses the email according to the Plus Addressing rules and then determines how to proceed.

1) Plus Addressing used in the email address section - if a work item reference number is recognized as part of any of an email's target mail addresses, that mail is shared with that work item.

The underlying structure of this is: [email connector address][+EnateRef][@email domain]

e.g. 'info+123-T@enate.io

What happens when a match cannot be found?

If no information can be identified to link the email to a currently running work item, the system will generate a brand new work item (Ticket or Case) based on the email’s configured routing rules. A confirmation email will be automatically sent back out to the requesting email address containing the reference number if the email route settings specified in Builder have ‘send response’ set to ‘on’.

When should I use Plus Addressing Only mode?

If your email server is configured to support plus addressing, we recommend that you use Plus Addressing Only mode. However, if you are transitioning from Plus Addressing OFF mode to include plus addressing, we recommend that you use mixed mode for a short amount of time to ease the transition before switching to Plus Addressing Only mode. See Mixed mode for more information.

Why would I ever move from Mixed to Plus Addressing Only Mode?

You might ask why you would bother moving on from Mixed mode into full Plus Addressing Only mode? Here is a business scenario which explains why running in fully Plus Addressing Only mode can be advantageous:

You can have a scenario where a query is sent in to the IT department. IT team sends a response back out from Enate informing the requester that this needs to be dealt with by HR (they may even even create a new Linked work item to for the HR department. Either way, further correspondence from the requester needs to go to the HR department, not the IT department.

If the original requester sends an email back in, removing the IT department's mailing address and making sure it is only being sent to the HR email address. How will this work in Mixed vs. Plus Addressing Only mode?

• If you are running in Mixed mode, there could well be the original 'guid' stamp in the email chain which states 'this came out of Enate from the IT department'. So Enate will use the standard email processing rules to match the incoming mail with the IT department's work item which is NOT what is wanted here.

• If pure Plus Addressing is used (i.e. Plus Addressing Only mode), then the mail won't go to the IT department. It will go to the HR department - either as a brand new request (if no plus addressing data was found), or into the existing HR request if plus addressing data for an HR work item was injected into the mail chain in a previous step.

In circumstances such as this where you want to fully switch a work item away from a department/team that was previously involved, you would want to use Plus Addressing Only mode and NOT Mixed mode. So, once you're comfortable that all open work items come from the point where Plus Addressing was switched on or later, we recommend you move to Plus Addressing Only mode.

Plus Addressing Additional Details

1. If an agent writing an outgoing mail includes an email address which Enate knows is linked to an Enate mailbox, when they click to send the mail Enate will display a popup showing them: - All currently linked work items which were created as a result of a mail into that same mailbox - An option to create a NEW (automatically linked) work item.

2. Once the agent has chosen existing work items / created a new linked work item(s) to share their mail with, the mail will be shared with them, and the email will be sent out to any external / non-Enate using parties. Additionally, the work item references of THIS work item AND the ones it is behind shared with will be added into the respective relevant mail addresses which are part of the outgoing mail. This ensures that on ALL subsequent email exchanges - coming either from internal parties or external / non-Enate parties, those work item 'tags' in the addresses route the mail to share it with the required work items. Further things to note...

3. If an incoming mail is replying to a closed work item, the system will create new one.

4. Live and test items cannot be addressed in a single mail.

Hide Work Item Matching Data in Email Addresses

There is an option to hide work item matching data in email addresses when using Plus Addressing. This is available just in the System Settings section of Builder, just below where you choose your Email Processing mode.

Enabling this will add a 'Reply To' header for outbound emails where work item matching data will NOT display as plus addresses in the 'From' address.

The impact of this is that if the setting is enabled, instead of seeing emails with

'jane.smith+12345-T@acmecorp.org' in the from field, it will instead show simply as

'jane.smith@acmecorp.org'.

See this article for further details.

Activities required outside of Enate

You must enable Plus Addressing in whichever email system you are using.

This article takes you through how to enable Plus Addressing in Microsoft 365:

This article shows you how to enable Plus Addressing in Gmail:

Creating a new type of Case

You are able to create new types of Cases within a Service Line itself by clicking on the '+' icon next to the search bar and selecting 'Case'.

When creating a new type of Case, you can enter the following information:

Configuring Steps for a Case Type

You can add, edit and delete the steps of a Case type from the Service Lines page. You can easily reorder the steps by dragging and dropping them. The Milestone % is optional, it denotes the progress reached when this step is completed and it displays in the Case form status tracker control.

When you delete a step, any Actions that were underneath that step will now display as ad hoc Actions. When a step is reordered, the Actions underneath that step will move with the step.

Effect on Live Case Processes

If you make changes to the steps of a Case type, live versions of Case processes of that Case type will not be affected. They will run as previously configured and the step changes won't apply until a new version of the Case process with the updated steps has been set live.

Updating a Case Process to Match Updated Steps

You will be notified in the Case process screen if its steps are out of date i.e. if changes have been made at a Case type-level when you are in edit mode.

You can click on the Refresh Steps icon in the header of the Case screen to refresh the steps to the latest version.

When you click to confirm, you will be shown which changes have been made:

Click OK to update the steps to match the steps configured at a Case-type level; new steps will be added to the Case process, steps in the Case process will be renamed, steps in the Case process will be moved along with the Actions underneath them and steps will be deleted and their Actions will become ad hoc Actions.

Effect on Cloning Case Processes

You can clone any Case process which is live under the same service line and all data such as Actions etc. will be cloned, except for schedules.

If the Case you are cloning has the same Case type, then the step names and Actions will all be copied across.

If the Case you are cloning has a different Case type, then the step names will not be copied across, instead they will appear like this:

Actions will be cloned across in their original positions i.e. Actions under the first step of the process being cloned will be the Actions under the first step of the Case process they have been cloned to. If there are more steps in the source process being cloned than in the Case it is being cloned to, the Actions under the "extra" step will become ad hoc Actions.

To update the steps in the Case to the latest version of its own Case type, click to refresh the steps in edit mode.

This will update the steps to the latest version in the Case type. If a step has been removed, any Actions that were underneath that step will now display as ad hoc Actions.

Subsequent Editing of a Case Type

To edit a Case type’s settings, click on the Case in the Service Lines Screen and edit the information in the right hand side of the screen. Click to save these changes.

You are also able to see the activity history of your work items , by clicking on the Show Activity button. You can see when the work item was created and by who, as well as if any edits have been made to the work item, when they were made, as well as by who.

You are also able to clone a Case type by clicking on the Clone button in the edit screen. This will clone all of the Case type's settings and data apart from its name. You are able to make changes to any of the settings and data once the Case type has been cloned.

Overview

'Manual' Actions let users send out manual emails to service recipients.

To use 'Manual' Actions, you need to create a 'Manual' Action type and then add the Action into your Case flows.

Creating a Manual Action Type

You can either create a Manual Action type in the Service Line section of Builder, or directly from your Case flow.

From the Service Lines Page

Creating a Manual Action type from the Service Lines page adds the Action type to your menu of available Actions when you're building flows subsequently in Cases.

To do this, in the Service Line page, select which service line you would like to add the Manual Action to and then click on the plus symbol next to the 'Process Search' box. This will bring up a drop down menu where you can select an Action.

This will open up a new Action for you to create.

Add a name and description to your Action and then in the type drop down select 'Manual Action with Peer Review'.

Once you are happy with your Action, hit save to create it. This Action can now be added to new and existing business processes by selecting it from the dropdown list when adding a new Action to a Case.

From a Case Flow

Alternatively you can add a Manual Action type directly from the Case flow itself.

To do this, open a Case flow in edit mode, click on an Action's menu and then instead of clicking to add an existing Action, select to create a new Action by clicking the '+' icon.

Give the Action a name, add a description if you wish and for its type, select 'Manual'.

This will add the Manual Action to the Case flow.

Configuring Manual Actions

You now need to configure the settings for the new Action you have added to your Case. Click on the Action in the flow to highlight it in the info section.

In the Action Info tab, you need to add the usual following information for an Action:

Additionally, once a Manual Action has been added to your Case flow, a new 'Email info' tab will display in the info grid.

Here you need to add the following settings that are only relevant for Manual, Send Email and Send Email and Wait Actions.

You can sync Enate to Microsoft Office 365 email boxes and pull emails into Enate without needing to use POP3 or IMAP protocols via Graph API Integration. Read below to find out how to go about this.

Register with Azure AD

To configure integration between Enate and Office 365, each unique Enate instance must be registered with the Microsoft Identity Platform in the Azure AD of the Office 365 tenant to which you need to establish connectivity.

To create the “App Registration” please follow the guide from Microsoft at https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app.

When configuring the Enate App Registration the supported account types option should be chosen based on the mailboxes you wish to access. No redirect URI is required.

Once the App Registration is complete you must add credentials and setup permissions.

To add the required permissions follow the guide at https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-web-apis. The only required API permission is an Application permission of Microsoft Graph\Mail.ReadWrite. It is important to select an “Application permission” and not a “Delegated permission”. Be sure to grant admin consent for the permission within the Azure AD tenant.

To create a credential follow the guide at https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-credentials-to-your-web-application. Enate supports Client Secrets and Certificates.

Finally to restrict the App Registration to only accessing certain mailboxes (strongly recommended) follow the Microsoft guide at https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access

Add Azure AD Data to Enate

After Azure AD has been configured to grant access, login to Enate Builder as a user with the “Can Edit Shared Configuration” permission.

Click the settings cog in the bottom left and open the “Office 365 Integration” pane and enter the details from your Azure AD App Registration.

The Tenant ID (aka Directory or Domain) and Application ID is shown on the Overview pane of the Azure AD App Registration; the client secret or certificate (and private key password) are supplied by you to both Azure AD and Enate.

Integrate with Office 365

You always use shared mailbox.

Click on the Office 365 Integration” pane and select whether you want to authenticate with a certificate (this is the recommended route as it is more secure), or whether you want to authenticate with client secret.

Authentication with Certificate (recommended)

As part of this set up, an Office365 Certificate would need to be generated - Generating a certificate is an activity for your Office365 Administrator to undertake, and is done completely independent of Enate. For your reference we have provided below a SAMPLE of the kind of PowerShell script that can be used to generate such a certificate. It will save the Certificate with the private key (for Enate) to a PFX file and without the private key (for Azure):

$pw = Read-Host -Prompt "Please enter a password for the Private Key" -AsSecureString
$name = Read-Host -Prompt "Please enter a name for the Certificate"
Write-Host "Creating Certifcate $Certname" -ForegroundColor Green
$Cert = New-SelfSignedCertificate -certstorelocation cert:\CurrentUser\my -Subject "CN=$name" -KeyExportPolicy Exportable -KeySpec Signature
$desktopPath = [Environment]::GetFolderPath("Desktop")
Write-Host "Exporting Certificate with Private Key to $desktopPath\$name.pfx" -ForegroundColor Green
Export-PfxCertificate -cert $Cert -FilePath $desktopPath\$name.pfx -Password $pw
Write-Host "Exporting Certificate with Public Key only to $desktopPath\$name.cer" -ForegroundColor Green
Export-Certificate -cert $Cert -FilePath $desktopPath\$name.cer

Enter the Tenant ID/Domain and the Application ID, select the 'Authentication with Certificate' option, add the certificate file ( Personal Information File, .pfx) and enter the password for the certificate file.

Then click to check the connection. Once the connection has been successfully tested, click to save.

You have now successfully configured your Office 365 integration.

Authentication with Client Secret

To authenticate with client secret code, enter the Tenant ID/Domain and the Application ID, select the 'Authentication with Client Secret' option, add the client secret code (this is generated by the network admin of your company).