Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
An Audit entry of all of the following activities is captured in Enate. Audits of system-generated activity are a time-stamped history of when the event occurred. Audits of user-generated activity contain both a time stamp and a record of the user account involved in the event.
This is the primary audit trail for process execution in Enate. It records when any work item changes status. Critically it records when users complete actions and tickets as the person accountable for the correct completion of that action.
Whenever a Work Item status is changed e.g. to In progress, To Do, Completed, Unable to Complete etc. these status changes are recorded in the system, with timestamp.
Any manual override to a system generated due date is recorded as a user-generated activity and audited as such.
Any change the due date is an audit of system-generated activity.
Push Allocations i.e. Manual Assignments where an Agent user allocates a piece of work to a user / clears the allocation, and Configuration-driven automatic assignments of work items to agent users (i.e. a system-generated event).
Pull Allocations where Agent users request and are auto-allocated a Work Item from Queues they work out of (recorded as a user-generated event), plus the upstream automatic activity where a Configuration-driven Queue assignment was carried out to allocate work into a work Queue.
The creation of internal Notes and manual sending of Outgoing Emails (with or without attachments) in a Work Item is an audit of user-generated activity.
The arrival of any inbound email is an audit of system generated activity.
Every time a user opens a work item in Enate regardless of whether the edit it or save it this is audited as user-generated activity.
Further, any manual adjustments to the auto-tracked time are recorded, along with timestamp of when the change was made, who made the change, what it ws changed from and to. Note that the originally auto-recorded time is NEVER lost in the Database, this record is persisted and the manual ‘adjustment’ is recoded as a new record.
Any change to security and access permissions is logged as an audit of user-generated activity. This includes a log the change made in the system that caused the user’s access to be changed. The changes that may result in the creation of security and access audit entries include (but are not limited to):
Creation, deletion, and changes to user accounts.
Creation, deletion, and changes to user groups.
Changes to objects accessible by user groups.
Changes to customer, contracts, services and processes that result in a change to user access.
Changes to role assigned to users (e.g. team leader)
The act of setting a Case or Ticket process Live in Enate is the moment that a change to the operational configuration is made. This restricted to those users with the ‘Release Manager’ role.
The act of setting a Case or Ticket process live is audited as user-generated activity.
All successful and failed attempts to create a User Session (i.e. log in to Enate) are logged as user-generated activity.
Every record in Enate is stamped with the date and time that it was last updated. This, in combination with the time tracking of agent activity within a work item, creates an additional interpreted audit for activities that are not directly audited.
For example the Universal Timestamp allows us to understand that a Defect on work item 1234-C-A1 was deleted at 2022/04/12 13:41:32 GMT. From the Agent Activity on a Work Item we can see that John Doe opened work item 1234-C-A1 at 2022/04/12 13:39:00 GMT and closed the work item at 2022/04/12 13:50:00 GMT. Therefore, John Doe deleted the Defect.
All updates to Enate are made through the Enate WebAPI. Every call to the Enate WebAPI whether the call is initiated from the Enate web applications (Work Manager or Builder) or a direct access to the Enate API (e.g. by an external system calling it) are logged as user-generated activity.
These logs are not available to End clients directly through the user interface but are managed as part of the Enate SaaS service in our log aggregation platform. They are available for either forensic requirements in response to security incidents or for detailed analysis of functional incidents by the Enate support team.
Technical requirements recommended as part of setting up your organisation to use an Enate instance.
With Enate you've got access to enhanced tooltips, explainers and inline help, plus content to let you know about new features when they appear. In order for these overlay explainers to show correctly in enate, you'll need to ensure that your company's security policy is set up to allow for the information to display (some companies policies can block this kind of information as a default).
Enate uses 'Userpilot' technology for its inline helpers to show. UserPilot uses Web Sockets to send data to client machines and requires that these work through any web proxies or firewalls that are configured within the customer environment. We've previously seen issues with the UserPilot Web Socket connection where proxies have been configured to perform SSL inspection against all traffic in the environment.
UserPilot provides the following list of addresses whichit is recommended to be whitelisted in order for the inline helpers to show correctly:
wss://api.userpilot.io
wss://analytex.userpilot.io
wss://analytex-us.userpilot.io
wss://analytex-eu.userpilot.io
wss://analytex-in.userpilot.io
wss://reporting.userpilot.io
Additionally, Enate requires that the following addresses are whitelisted to serve Enate specific media embedded within UserPilot experiences:
For further information on UserPilot security setup requirements, please see the following link: https://docs.userpilot.com/article/152-faq-content-security-policy
Enate also uses some feature usage services to help us improve our software features based on how it's used. For this to work correctly, the following url should also be whitelisted:
The file below shows a list of the open source components used in Enate:
The length of time an individual Agent user has spent on a work item is tracked, broken out into each individual session the user works on the Work item. Combined overall length of time spent on a Work Item by all Agent users is also recorded. See Enate Online Help article for details of .
Please be aware that the Enate solution does not provide additional anti-malware scanning of file attachments uploaded or ingested by the service.
Customers should ensure that their sources of file ingestion (incoming Emails and manual uploads to Work Items from staff laptops etc.) have adequate malware scanning capabilities in place prior to a file being presented to the Enate platform.
This article outlines the steps to follow to configure SSO in Azure Active Directory.
1) Register a new application from the Enterprise Application | All Applications screen in the Azure Active Directory portal: https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AppAppsPreview/menuId/
2) Create a new non-gallery application. Including SSO or SAML in the name for this application can help to distinguish this from future GraphAPI applications for the same instance.
3) Once the application has been created and the configuration pages are visible, navigate to Single sign-on under the Manage section and select SAML.
4) Enate will supply an XML metadata file for each instance. This can be imported using the “Upload metadata file” button at the top of the page.
5) Once imported, verify that the Identifier (Entity ID) and the Reply URL (Assertion Consumer Service URL) have been populated and the press Save.
6) On the Single sign-on page with the newly populated Basic SAML Configuration section, you should be able to download the Federation Metadata XML under section 3, SAML Signing Certificate.
Note: Enate typically uses the Email Address field configured for users within Enate to validate claims. This must match one of the supplied claims. User.userprincipalname or user.mail typically satisfy this but if you domain has multiple email addresses or situations where the userprincipalname may not always match the email address you may need to transform a claim to provide the correct information.
7) This downloaded XML file should be supplied to Enate to complete the Enate side of the SSO configuration prior to testing.
8) On the Properties page under the Manage section, you should change the “Visible to users?” setting to “No”.
9) Depending on your configuration you can also change the “Assignment required?” to “No” and then manually assign Users to the application under the Users and groups page under the Manage section.
Binary storage is utilized for storing large files. At Enate, we employ it to store raw communications, communication attachments, files attached to work items, and files exported from Advanced Search views.
Enate is always provisioned with the primary binary storage configured in an Enate Azure tenant. You can see details of your Binary Storage locations in the 'Azure Binary Storage' section of the System Settings in Builder.
However, you can if you wish choose to change where your binary data is stored, and switch this to be your own Azure tenant.
Important note: Changing your Binary storage location will not transfer your existing data to the new location. You should exercise extreme care when making this change, in order to avoid irrevocable loss of binary data. You should contact Enate's Customer Success team if you wish to make such a change, so the activity can be carried out with our team's advice.
To enable this feature of setting your own storage locations, you will need to perform activities outside Enate as well as within this section of Builder. You will need to do the following:
Create two Azure Storage Accounts in two separate Azure Regions within your Azure tenant. We recommend that one of these regions is Europe West to maximise performance.
Create an Azure App Registration that is granted access to these storage accounts.
Configure Enate to use these storage accounts rather than the Enate Default.
NOTE: If your organisation is not proficient at managing Azure storage then you should NOT adopt this option. Deletion or corruption of data in these storage accounts will result in immediate and irrevocable data loss.
To add a new Storage Location in Enate, click the '+' icon in the Azure Binary Storage section in Builder's system settings. This will show a popup where details of the new Storage location you have set up in Azure should be entered:
The general data asked for is as follows:
Important Note: Once you set the encryption key and key size here, they cannot be changes. You must ensure that you securely save the encryption key as it cannot be modified later.
In addition to these General settings, there is also information to fill in on the Azure details tab:
You can generate Certificates or upload an existing on by selecting the 'Authentication ith Certificate' option on the Azure details tab. This will bring up a further popup to allow you to generate or upload a certificate:
If you fill in the Subject here and click on Submit, a certificate will be generates and you will be given a Download link to allow you to download the public key certificate.
You should upload this Certificate in the Azure app registration 'certificate and secret' section.
Note: You need to make sure that you upload the certificate / create the secret in Azure App Registration before saving, as the configuration will not save until it can successfully test that all the information provided is correct.
Alternatively you can Upload an existing certificate if you have one.
Once you have entered all required information you can Test your connection and, once successfully tested, save it.
Once you have successfully created your own Azure storage locations and linked it to your Enate instance, yo can choose to set that location as your primary storage location. You will be met with a popup asking you to confirm your decision, and reminding you that your existing data will NOT be automatically transferred to the new location.
Access to being able to modify these settings should be tightly controlled. Access is managed via the 'Binary Storage' access option within Builder User Roles setup, under the 'Edit System Settings' section:
When dealing with storage locations and encryption keys for Binary data, there are a number of important points to keep in mind:
Only one single Binary Storage location can be active at one time.
You cannot be make any updates to or delete any Enate-managed Binary Storage.
The Encryption Key and Size cannot be changed after creating
While you can switch between binary storage configurations, this will NOT automatically migrate any of your existing data, so you must exercise extreme caution when choosing this option.
You can only delete a Storage location if that configuration has yet to ever be used (And you cannot do this at all with any Enate-managed storage locations).
Management of your Certificates / Secrets with regards to e.g. expiry of these is completely managed be you, and no management of these is provided by Enate.
To reiterate: If you are thinking of changing you Binary Storage location settings, we stringly recommend that you contact Enate's Customer Success team, so the activity can be carried out with our team's advice.
Engines in Enate are categorised into 2 different types. “Polling Engine” and “Message Handler Engine”. Polling Engines perform a specific task either at a regular interval or a fixed time of day. “Message Handler Engines” perform a task on demand when an event is triggered elsewhere in Enate.
The Default Polling Frequency is the Enate recommended value. Engines that poll at a fixed time of day should be configured to run during quiet hours on the platform.
Item | Details |
---|---|
Item | Details |
---|---|
Name
A Name for this Binary Storage Location
Description
A Description for this Binary Storage Location
Primary Endpoint
The first Azure storage location primary endpoint URL
Secondary Endpoint
The second Azure storage location primary endpoint URL
Container Name
The exact container name of first Azure storage account. NOTE: both the first and second storage account must have the same container name.
Key Size
This will be used to encrypt and decrypt binary data.
Encryption Key (plus Confirmation)
This secret key will be used to encrypt and decrypt binary data.
Tenant ID or Domain
Get this from the registered app 'Host Name' in the overview menu in Azure
Application ID
Get this from the registered app 'Application (client) ID' in the overview menu in Azure
Authentication with Certificate / with Client Secret
You can generate a secret in the Azure app registration certification and secret section, however Enate recommends using the Certificate approach here.
Name
Description
Default Polling Frequency / Time
Abbyy Batch Processing Engine
Submits any new batches created in Enate by Abbyy Actions and monitors existing batches in Abbyy for updates.
Every 1 minute
Abbyy Project Data Sync Engine
Imports the list of Projects available in Abbyy for users to select in Enate Builder when configuring Abbyy Actions.
Every 5 minutes
Data Cleanup Engine
Removes old background/temporary data from the Enate database.
23:00 every day
Data Export Integrity Engine
Checks all Work Items to ensure they are up to date in the warehouse database.
23:30 every day
Email Message Receiver Engine
Downloads messages from configured Email Servers and stores them in the Enate database for subsequent processing by the “Email Message Processor Engine”.
Every 1 minute
Email Message Sender Engine
Sends all queued emails out from Enate.
Every 30 seconds
External Binary Data Pending Item Engine
Removes files that were uploaded to external (blob) storage systems from within a database transaction that was rolled back; leaving orphaned files in the blob storage system.
Every 60 minutes
Fixed Frequency Scheduling Engine
Evaluates all configured Triggers in Enate and queues up a message to start a Case at the appropriate time.
Every 1 minute
Robot Six Sigma Calculation Engine
Calculates the performance of Robots and disables slow Robots if configured to do so.
00:00 every day
RPA Sync Engine
Imports the list of Robot Farms and Robots from all deeply integrated RPA platforms.
Updates the password of Robot user accounts and updates the RPA platform with the new credentials.
Every 5 minutes
Scheduling Engine
Evaluates all configured Schedule Periods in Enate and creates a new Case for any Schedules where the Start Date is reached an existing Case linked to the Schedule Period is not found.
Every 5 minutes
Timeout Engine
Checks running Work Items for any timeout that has passed (e.g. Feedback window, Wait for more information until, Wait until fixed date, etc) and performs the appropriate action.
Every 5 minutes
Trigger External API Engine
Calls out to external APIs when required by External API Actions.
Every 1 minute
User Session Clean-up Engine
Ends any idle sessions that are beyond the configured “Idle Session Timeout”.
Ends any active sessions that are beyond the configured “Active Session Timeout”.
Updates any open Activity Tracking record for a closed session to be closed/completed as appropriate.
Every 5 minutes
Name
Description
Data Export Engine
Copies operational and configuration data from the Core Enate database to the Warehouse database used by reporting.
Data Export Permission Data Engine
Copies access rights records from the Core Enate database to the Warehouse database used by reporting.
Email Message Processor Engine
Parses a received email and associates it to an existing Work Item or creates a new Work Item as appropriate.
Launch Process Engine
Starts a Case that has been triggered by the “Fixed Frequency Scheduling” Engine.
Localisation Cache Updater
Updates inherited languages after a change to a localised value (Name, Description, etc). For example, changing the “English” value will update all languages that do not specify a localised value.
Triggers the “Packet Metadata Updater” Engine for the updated business object.
Packet Metadata Updater
When triggered for a business object calculates all impacted Work Items and queues up a message for itself.
When triggered for a Work Item updates the localised values of a Work Item into the database Full Text Search capability used by Quick Find.
Permission Cache Update Engine
Updates the access permissions of a User base on their User Group membership.
RPA Sync Start Integration Process Engine
Triggers a Robot linked to a deeply integrated RPA platform.
Schema Management Engine For Custom Data
Updates the Warehouse database schema for Custom Data fields.
Schema Management Engine For Entity Structures
Updates the Warehouse database schema for User Extension properties.
Schema Management Engine For Schedule Structure
Updates the Warehouse database schema for Schedule Structures.
User Group Permission Cache Update Engine
Updates the access permissions of a User Group.
Triggers the “Permission Cache Update Engine” Engine for all Users within the User Group.
User QuickFind FullTextSearch Engine
Updates the searchable fields of a User into the database Full Text Search capability used by Quick Find.
Webhook Message Creator Engine
Looks for Webhook subscriptions and queues up messages for the “Webhook Message Sending Engine” Engine.
Webhook Message Sending Engine
Calls out to external APIs in response to a Webhook event occuring.