Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A ‘Wait for Sub-Cases to Complete’ Action will wait for a specific Sub-Case to reach completion before allowing the Case to move on to the next Action.
You can tell that an Action is a ‘Wait for Sub-Cases to Complete’ Action because it will say 'Action is waiting for Sub-Case to complete' in the Action's info card.
Once a ‘Wait for Sub-Cases to Complete’ Action has been launched AND the Sub-Case it has been set to wait for has been launched (either manually or through a 'Start Case' Action), the ‘Wait for Sub-Cases to Complete’ Action will move into a state of 'Waiting'.
Once the Sub-Case is completed, the 'Wait for Sub-Cases to Complete' Action will close automatically.
You will be notified of this in the timeline as well.
If the Sub-Case the 'Wait for Sub-Cases to Complete’ Action is set to wait for it not available - either because it has not been launched or because it was resolved before the ‘Wait for Sub-Cases to Complete’ Action was launched, the ‘Wait for Sub-Cases to Complete’ Action will enter a state of 'To Do' and be assigned to a Queue where a user will pick it up and decide how to proceed.
If you then try to set the 'Waiting for Sub-Case to Complete' Action to 'Waiting', the Action will close as the Sub-Case it is set to wait for hasn't been launched.
If the Action is not in a 'Wait for Sub-Cases to Complete' state and the Sub-Case for which it is waiting has been completed, a message will appear as 'Sub-Case is completed' in the Info Card.
If you manually Resolve a ‘Wait for Sub-Case to Complete’ Action, the Action will be marked as Resolved without the Sub-Case having completed.
Please note that if your system has been configured to auto-close a 'Wait for Sub-Case to complete' Action (see here for more information about how to do that) and the Sub Case the 'Wait for Sub-Cases to Complete’ Action is set to wait for is not available - either because it has not been launched or because it was resolved before the ‘Wait for Sub-Cases to Complete’ Action was launched, the ‘Wait for Sub-Cases to Complete’ Action will automatically move to a state of Closed. You will be notified of this in the timeline.
The Action screen has the same overall layout as the and screen, and the same basic features including to a work item, , viewing the and viewing the , but the Action screen also contains some Action-specific features.
At the top of the Action screen, you'll see the title of the Action, made up of:
Customer name - Contract name - Service name - Case Process name - Action Process name
For example:
The title of an Action is automatically set and is not editable.
'Action Reference - Case Short Description - Action Process Name' '10040-C-A1.1 - Jack Jones new starter - HR Approval'
Note that the Case Short Description cannot be edited directly from an Action.
This is the name that will be shown in the Action tab:
The Case's short description is also the title that will also appear in the 'Title' column of the homepage grid for the Action.
You can copy the Action's reference and number by clicking on the copy icon in the tab:
The Action's due date will display, colour-coded to show if the date is:
On schedule:
Due today:
Late:
If an Action has been configured with an override due date option in Builder, then you will be able to override the due date of an Action by clicking on the due date in the header and changing the date in the popup.
You can also see whether or not the Action has been assigned, and who to.
You are able to reassign and unassign an Action, or assign the Action to yourself if it has not been assigned to you already.
See here for more information about assigning work in Enate:
In the Info Card you can see the status of the Action and change the status as needed.
The main label on the left side of the Info card will display the status the Action is currently in. The dropdown button on the right side gives options for the states which you can move it into as part of processing.
See here for more information about processing an Action:
Once you have selected the new status from the dropdown and filled in any further required information, click the button to confirm.
The border of the Info Card highlights in a colour relating to the current status – once you have clicked the button to change status, the system will process the changes – the border colour and new status will change to confirm that the status update has occurred.
When changing the status of a work item, if you are moving it to a state of 'In Progress', the work item tab will remain open upon confirming the new status. When changing to any other status, e.g. 'Wait' or 'Rejected', the tab will automatically close. A label under the Status will inform you of this in advance.
In addition to showing the Action's status, the following information is displayed directly underneath:
Set by - who set the status
Reason - the status change reason - i.e. why was it changed, this could be manual or as part of a process)
Date - when the status was changed
Last Updated By - who last changed some data on the Action
Last Updated On - when some data was last changed on the Action.
Note that not all of the above information will be displayed every time, the information that is shown depends on the status of the Action and how the Action has been configured in Builder.
The Settings Card shows you detailed information about the Action, including:
The Action's context (Customer>Contract>Service>Case Process). This cannot be modified.
Action Instructions
The Action's parent Case, a link to the parent Case and a symbol showing the state of the Case
When the Action was created and who by
If this Action was created from another work item, the initial request date shows the start date of the original request, allowing you to capture the entire length of time it has taken to complete a request.
Keep with me - users who have this option selected will be auto assigned as the work item's owner or assignee. This can still be changed manually.
Record Count - depending on configuration for the Action in Builder, the record count may or may not be displayed here. If it is, the record count is editable. If you update the record count for an Action, it will update the record count for future Actions but not previous Actions that have been closed.
By default, the available relationships are:
Primary Contact – the main person you are dealing with for this Action.
Requester – the person that raised the initial request.
Subject – who the Action is about (this may be neither of the above).
Very often all three will be the same person.
CCs – any further contacts which can be copied on any correspondence. When a contact is tagged only as ‘CC’, it will be displayed in the separate CCs section (hidden until any CC-only contacts exist on the work item.
If you search for a user in the contacts card that does not exist in the system, you can create a new contact by clicking on the ‘Create Contact’ option and filling in the contact's details.
If you have written the email address for the contact, the system will decode and auto-populate the first name and last name of the contact. Once you fill in all the information and click on create contact, the system will redirect you back to the work item.
When you manually add a contact they will be set as the Primary Contact, Requester and Subject by default. You can manually reassign these tags to other users afterwards.
To help you manage activity against your SLAs, Enate allows users to track the time it takes for work items to be completed, both as an overall total and broken out by the various resources who may have worked on it.
The Time Tracker Card in work items tracks the time of each individual browser session that the item is worked on.
See here for more information about time tracking:
Additionally, a Custom Card can be configured to display custom data..
See here for more information:
When you're working on a Ticket, Action or Case, operational issues can occur which have an effect on how you're able to deliver the process. It is important to record these as a way to highlight them for others who may view or work on the item, and to help with longer term efforts to improve process delivery.
Watch this video to find out more about recording defects in Enate.
You can also go to the dedicated article to find out more:
In order to mark an Action as complete, you must confirm for each item in the checklist whether you have completed it (the options are Yes, No, N/A) and you may need to add a note for each check.
You can also see the name of the person who last updated the item in the checklist and when this update was made.
If issues have occurred during the running of a Case you may wish to rework the Case. You can do this from an Action by selecting the ‘Rework’ tab from the Action screen.
See here to find out more about reworking a Case from an Action:
Most often the Actions in a Case are started automatically (either by process flow or based on schedules). However, if an Action has been configured to be manually startable, you can do this from an Action using the 'Start Action' feature.
See here to find out more about manually launching an Action from an Action:
When a new email has come in for the Action that hasn't been read yet, the New Information icon will be highlighted. Clicking on it shows you when the new email was received.
You can choose to mark the new information as read which will set the New Information icon back to normal. You can also mark the information as unread by clicking on the 'Mark as New' option.
You can view how the Case that the Action belongs to is progressing by clicking on the map icon. will bring up the Case progress popup. This displays the progress made on steps in the Case, showing completed steps in green, the current step in orange and future steps in grey.
If you do not want any percentages to show here, simply leave them blank when configuring the Case’s steps in Builder.
This provides a link to the Standard Operating Procedure for the work item that has been set in Builder.
If the , the changes to Case Short Description will be reflected in the Actions Screens of all the Case's Actions (you may need to refresh your Action screen for this to take immediate effect) and the title of the Action will be made up of:
The is where you can specify the people who relate to the Action.
Note: it is possible to add further relationship types into the system. See here for more information on how to .
An Action's contacts will usually be auto-populated as the same as the contacts for the parent Case. However, if the Action's contacts are not auto-populated or if you want to add a different contact to the Action, you can add contacts to the Action manually by searching for them in the . This change will also be reflected in the Case's contacts too.
Some Actions have a checklist section. This shows the checks which are required for this Action - defined during its .
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.
This component can be switched on by your admin in the Marketplace section of Enate Builder.
Check out this video to find out more:
When the Case is run in Work Manager, relevant data from files attached to incoming emails for it will be automatically analyzed and extracted.
If the technology you're using is confident enough about its data extraction results, this Action won't even need to be seen by a human user, it will simply be completed automatically and the Case will move on to the next Action. The completed data extraction Action can still be viewed if you click on it, but it won't need to be handed over to a human user for involvement.
However, if the extraction technology is less confident in its data extraction results, the Action will be handed over to a human user when you next hit 'pull from Queue' in their home page, to pick up and look over. When an agent opens the Action, you'll see that it's been given to them because some further checks are required.
To do this, you just needs to click on 'Verify Now' and scroll to the 'validation station' screen in the Action, which shows the scanned document image and the resulting extracted table of data values. This lets you see where those lower confidence levels are highlighted, review them and make any necessary corrections manually. This can viewed in-situ, or expanded out to a popup to display full screen.
Every time this is done, the technology will learn and get a little bit better at its data extraction suggestions. If you notice that the technology is regularly getting its suggestions wrong, speak to your admin team about modifying the confidence threshold.
Once you are happy that the extracted data is as desired, you can click to mark the Action as completed successfully.
Enate is able to provide integration with ABBYY FlexiCapture - this is achieved through use of an ABBYY FlexiCapture integrated Action (see the here for guidance on how to create and configure this new Action type).
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.
Note: Only filetypes supported by ABBYY v12 onwards can be submitted. Click here to see the following link for list of formats supported by ABBYY.
The system will show this message while it is waiting for you to submit document(s) to the ABBYY FlexiCapture engine for processing:
You’ll see confirmation of when documents have successfully been submitted to ABBYY for processing:
Last attempt is the time when the document(s) have been submitted to the ABBYY FlexiCapture engine for processing.
If the documents submitted were of an invalid file format or if there were problems with the formatting of the document itself, the system will return this message:
If there has been an issue with document submission, the system will automatically retry submitting a certain number of times, depending on how your system has been configured in Builder (see here for more information).
If there is still a problem with submission following the automatic retries (e.g. if the retry setting is set to 5 and the system fails to establish a connection following 5 automatic retries), the ABBYY Action will move to a state of 'Closed'.
In this circumstance of the Action failing to establish connection with the external sytem, this will escalate to the Case Owner, highlighting in the Action section of the Case screen that this Action was Closed - Not Done Successfully.
After having scanned a document, ABBYY creates a score based on how confident it is in the quality of the scan. If the confidence score is above the threshold defined then no verification is required and it will process the data and complete the task. If the confidence score is below a certain threshold, human verification is required.
A status message will confirm that human validation is not required:
Once processing is complete, the ABBYY Action will close. Exported files will be attached to the Case and are visible in the Files Card.
Note: if Output File Tags’ have been set then ABBYY will apply the output tag to all files which it processed, ready for use in downstream activities.
The system will alert you if human verification is required:
Additionally, a reminder text will display in next to the Action status to reaffirm that manual verification must be completed in ABBYY before continuing.
Clicking on the ‘Verify’ button will take you to the ABBYY Verification Station where you can verify the scans of the documents and adjust information as necessary.
Note : A valid ABBYY FlexiCapture account with permissions to carry out verification in the chosen project will be required for full access.
Once you are logged in, you will be presented with ABBY FlexiCapture’s Verification Station screen where you can review and adjust information as necessary.
The Verification Station is made up of three sections:
The individual pages of the document to be scanned.
A close up of the original document to be scanned.
The Extracted Output - so the scanned version of the original document.
Text highlighted in yellow in the original document tab is the data ABBYY is unable to read. This is highlighted in red in the Extracted Output.
Certain characters like ‘i’ may also been highlighted Extracted Output section if ABBYY is uncertain about the scanned copy.
Once you’ve finished the manual verification, the screen will confirm this has been done but will note that there was an expectation which required manual intervention:
Once processing is complete, exported files will be attached to the Case and are visible in the Files tab.
You can then mark the Action as complete.
Note: if Output File Tags’ have been set then ABBYY will apply the output tag to all files which it processed, ready for use in downstream activities.
Details around how to configure actions to trigger external APIs, and how they will display in Work Manager for operational users.
Similar to other action archetypes, 'Trigger External API' actions can be used in Case processes, and are used for 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.
For information on how to configure 'Trigger External API' Actions check out this Builder section.
Sometimes there can be a delay when waiting for the external system to respond. When that happens, i.e. when the ‘Trigger External API’ Action is waiting for information to come back from an external system, the Action info card will display in Work Manager as being in a state of 'Waiting'.
When the external system ultimately responds to Enate with the data update, it will be with a marker to say whether it has been successful OR unsuccessful:
If the system is responding to say it has been successful, the Action will automatically move to a state of 'Closed', with a Resolution Method of 'Done Successfully'.
Response with Unsuccessful Completion
If the system is responding to say it has been unsuccessful, the Action move into a state of 'To Do', with a reason of 'Updated by Integration'. The external API can also respond with additional information regarding why it was unsuccessful. This information will display in the Info card of the Action in the 'Rejected Reason' section.
If the Action isn't successful because it did not complete within the time set for it (configured in Builder), then it will moved to a state of 'To Do' with a reason of 'Timeout' and it will allocate to a Queue / human user based on the configured allocation rules.
Such unsuccessful Actions will now effectively behave as a standard manual action.
Please note that the Case owner will NOT be notified in these situations.
If the Action is not able to connect to the external system, it will automatically retry connecting for a certain number of times, depending on how your system has been configured in Builder (see here for more information). You will also be shown an error message bar on the Action showing:
when the error occurred
when the system will retry establishing a connection automatically
how many times the system has automatically retried establishing a connection, and
how many times the system will automatically retry establishing a connection.
You are able to manually retry establishing a connection from here too, by clicking the 'Retry' link in the error message.
Please note that when you do a manual retry, this will be counted as an attempted retry and will therefore be included in the number showing how many times the system has 'automatically' retried establishing a connection.
If the Action fails to establish a connection following the automatic retries (e.g. if the retry setting is set to 5 and the system fails to establish a connection following 5 automatic retries), it will move to a state of 'Closed' with a resolution method of 'Not Done Successfully'.
In this circumstance of the Action failing to establish connection with the external system, this will escalate to the Case Owner, highlighting in the Action section of the Case screen that this Action was Closed - Not Done Successfully.
When the Action receives the required information, it will close automatically.
If the automatic retry setting in Builder is changed after the system has automatically retried establishing a connection with an external system, the following will occur:
If, for example, the retry setting was originally set to 5 and the system automatically retried establishing a connection 5 times but failed, the Action will have moved to a state of Closed with an error message showing a retry count of 5/5.
If the retry setting then gets subsequently increased to anything above 5, for example 7, the error message will display a retry count of 5/7, but the system will NOT automatically retry establishing a connection for a 6th and 7th time as the Action is already closed.
However, if the Action had not yet moved to a state of Closed because it had not yet reached the maximum number of automatic retries (e.g. it had only retried 4 times out of the 5), then increasing the retry setting to 7 means that the Action will automatically retry establishing connecting until the count has reached 7.
Conversely, if you reduce the retry setting after retries have started, e.g. you're on retry 4 of 10 but then reduce the max down to 4, the system will still display 4 of 10 but will in fact be closed.
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 approval request scenarios in a more integrated way - to ensure that this 'approval cycle' is tightly managed and visible within the flow of activities in Enate.
Approval requests get sent out to agents working externally from Enate to approve or decline.
There are a few different types of approval that affect how the decision is made:
In a multilevel scenario, the request email is sent to each new level upon successful approval from previous, up to a maximum of 3 levels. If any person declines, the approval is declined.
In a parallel any scenario, the request email is sent to all approvers and the first decision is taken.
In a parallel all scenario, the request email is sent to all approvers and ALL must approve for the request to be approved. If any decline, the approval is declined.
If the request gets approved by all necessary parties, the approval Action gets successfully resolved and closed automatically, so no Work Manager Agent will need to pick it up, although the closed Action can always be viewed by manually clicking on it.
There are, however, a couple of scenarios where a Work Manager agent might need to pick up and carry out any required activities to further process an approval Action:
The approval has been declined
No approvers (or insufficient approvers) have been determined automatically
In the scenario where an approval request has been declined, the Action will move into a state of 'To Do' and so will ultimately need to be dealt with by a Work Manager Agent. They should review the approval decline reason provided by the approver and decide how to proceed. They can either:
Update as needed and Resend the request by setting the Action to 'Wait'. This will auto-send out the approval request email again** and place the Action in a state of 'Wait for More Information' - since we're waiting for external information (an approval response) to be registered back into the system before activity can proceed.
Mark the Action as Unable to complete. This will alert the Case owner who then needs to decide how to proceed - perhaps by reworking the Case or closing the Case entirely.
Mark the Action as Resolved which will manually mark the request as approved. The Case with then progress to the next Action.
**Note: Approval request email sending will start again from the beginning, i.e. all requesters will be mailed again. If they click on any previously sent emails, they will be met with a message telling them that THAT specific approval request is no longer valid, as the details of what is being requested may have changed).
In the scenario where an agent needs to add in approvers because one or more required approvers is blank (or make changes which result in the approval requests needing to be sent out again), the Agent will pick up the Approval Action in a state of To Do. Once they have finished making any adjustments and / or filling in missing Approver names, the must then place the Action in a state of Wait. Once they do this will auto-send the approval request email and then move the Action to a state of 'Wait for more information' as it is waiting for external info (approval) before proceeding.
Note: While an Approval Action is state of 'To Do', or 'In Progress', external parties who were mailed out approval requests will NOT be able to approve or decline. Instead the will be met with a message informing them that the item in question is currently being processed. Work Manager Agents MUST move the Action back to a state of 'Wait for more information' if they wish the approval activity to recommence.
Another potential scenario is that the approval Action might auto-close because it has timed out as no/insufficient responses were received in time. In this case, the Action will automatically be set to Resolved, and the Case will continue. No Work Manager agent will need to pick up an Action in this scenario, although the closed Action can always be viewed by manually clicking on it.
An Action in Enate will begin in a status of ‘To Do’ until a resource has picked it up - this could be a human resource or a robot resource.
Once you start updating an Action sitting in this state, it will:
automatically assign to you and
the status will change to ‘In progress’
You can also choose to change the state yourself. This signifies that work is now underway and it will stay in 'In Progress' until it’s resolved – assuming e.g. no waiting for further information.
If you’ve picked up an Action in error, or if your reach the conclusion that it’s not a piece of work you’re going to be able to progress you can unassign it from yourself, either to another resource or just back to its Queue. This could be after 10 seconds or half an hour, but when you do this the system will automatically set the status back to ‘To Do’ to let everyone know that it’s not going to be progressed until another resource picks it up. You can also just manually set the status back to ‘To Do’ if for example you started working on it in error and need to quickly undo the status change.
Similarly if a robot resource rejects a piece of work its status will be set back to ‘To Do’ as part of handing it over for a human resource to carry out.
If you’re working on an Action and you have to temporarily halt work on it because you’re waiting for some additional information or because of some other temporary blocker, you should choose the ‘Wait’ status.
When placing an Action into a state of 'Wait', you need to specify the type of wait. The options are:
Impact on SLA clock: SLA clock PAUSES while an Action is in this state, IF the Action's due date rule (configured during process design) has 'Add Wait Time To Due Date' set to ON. If it is set to OFF, the SLA clock CONTINUES while the Action is in this state.
If you’re working on an Action and you have to temporarily halt work on it because you’re waiting for some for some information from a third party or client, you should choose 'Wait for more information'.
Upon confirming the 'Wait for more information' status, the Action will move from your Work Inbox into your Owned Work list, as there is no active work to be carried out on it until a response is received.
Once a response has been received, the Action will move back from your Owned Work list into your Work Inbox in a state of To Do, highlighted for you to progress.
Impact on SLA clock: SLA clock CONTINUES while the Action is in this state.
If you’re working on an Action and you have to temporarily halt work on it until a specific future date/time, you should choose 'Wait Until'.
When you select 'Wait Until', you must specify the desired follow up date and time.
Upon confirming the 'Wait Until' status, the Action will move from your Work Inbox into your Owned Work list, as there is no active work to be carried out on it until the follow up date.
When this date is reached, the Action will move back from your Owned Work list into your Work Inbox in a state of To Do, highlighted for you to progress.
You signify completing the Action by marking it as Resolved.
Along with this there are two options to specify how the Action was resolved:
Complete
Unable to complete
Set this option if you cannot complete the required activity. Once you have confirmed this option, the Action will be closed and cannot be re-opened. The Case Owner will be notified of this and be asked to take the necessary steps to resolve at Case level. This may involve starting another copy of the Action, reworking the Case from a previous step, or moving on.
Enter the reason you are unable to complete the Action and hit the ‘can’t Complete’ button to confirm. The tab will close.
After the Action has been resolved, it will move to a state of 'Closed'.
Any subsequent mails received will launch a brand new work item. Once you have selected this, the Action will be closed and cannot be re-opened.
Note: You can easily move an item from 'To Do' straight through to resolved.
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.
Peer Review Actions involve two parts: the first part is completing the Action, done by one user. The second part involves reviewing the Action to check it was completed correctly, done by a different user.
Watch this video for a quick overview about how to use Peer Review Actions in Work Manager:
The Peer Review Action will first appear in a state of 'To Do' to the user who is tasked with completing the Action.
The peer review symbol will let you know if you are completing an Action that is then going to be reviewed by a peer:
The first user needs to complete the Action as normal and mark it as 'Resolved'.
Once the Action has been completed and marked as 'Resolved', the Action is then assigned to a different user to review, back in a state of 'To Do'.
Note: The person who carried out the manual activity cannot also perform the peer review activity.
The peer review symbol will let you know if you are peer reviewing an Action that was completed by a colleague:
When you are on the screen of the Action which is being peer reviewed, you'll see a Peer Review text box along the top, allowing the reviewer to add any overall comments relating to reviewing how the Action was completed.
The checklist is only available when the Action is in a state of 'To Do' and only the assigned reviewer is able to edit the checklist.
Once you have finished your review activity, switch the status of the Action to resolve and then choose if the review was a Pass, Fail or was Unable to be completed and then click to confirm.
If you're happy to approve the activity, selecting 'Pass' will mark it as such and will close the Action on-screen. You can add a comment, but it is not mandatory.
If you then click to re-display the action, you'll see that next to Peer Review it now says Passed, and any comments entered can be read.
If the Action has not been done correctly, you should select 'Fail' and must add a comment in the Peer Review Comments section with the details of why.
Submitting the review will then return this Action back to the agent who carried out the original activity in a state of 'To Do'.
When that original agent opens the Action, they'll see 'Failed' next to the peer review, and will be able to read all of the comments left by the reviewer.
Their role now is obviously to redo that activity to correct the issues raised, then once again mark it as resolved. It will then be routed through to the reviewer again to carry our another peer review.
The other option is that the reviewer is unable to successfully carry out a review. In this circumstance they should select 'Unable to complete'. The system will then ask the reviewer to provide a reason as to why they were unable to complete the review.
Once that has been provided, they can mark the Action as resolved.
This closes the Action and marks it as 'not done successfully'. This escalates up to the Case, which will now display a warning symbol and the notification that the case needs intervention in order to move forward.
It IS sometimes the case that the peer review activity gets automatically bypassed if it meets certain criteria set as part of the Case configuration.
If that happens, then as soon as the manual Action is completed, the system will move straight on to the next Action and will avoid routing the work to someone to peer review.
Further to this, a note will subsequently be displayed in the Actions list on the Case screen, showing that the peer review activity was not required.
'Send Email' Actions involve Enate auto-sending an email and then the Action will immediately close. Work Manager Users should not have to do any work on this type of Action.
'Send Email and Wait' Actions involve Enate auto-sending an email. The Action will then move to a state of Waiting until a response has been received. Once a response has been received, the Action will move to a state of To Do to be processed further.
The To address and any CC or BCC addresses on the email are configured in Builder - see this article about how to configure 'Send Email' Actions in Builder:
Once the email has been sent, an entry will appear in the timeline showing when it was sent, who it sent from and to, any CC or BCC addresses, the email subject and if you click to expand, the email body itself.
If an invalid To, CC or BCC email address is used, the email for the Send Email/Send Email and Wait Action will fail to auto-send and the Action will then be moved back to its Queue.
A warning will appear in the timeline:
The Case owner can then decide if they want to manually send the email and will need to correct the email address and add the email body manually. They should also contact their system administrator to alert them about the issue so that they can correct the email address to prevent future email failure.
