AD metadata capture

MoSCoW Rating for Deimos Release:

Must

Business Case

The Enhanced Active Directory (AD) Metadata feature provides additional metadata from associated AD accounts. The feature will be used for supporting playback permissions. In the future it can also be used to support data export to the Red Box Azure Bridge (for sending to an Azure Blob Container) but can also be used to simply provide enhanced metadata for recordings.

There are a number of additional future user cases for this functionally including:

Ability to pull language from AD to help with transcriptions
If their PC was stored in AD, we could use that information to help control screen recording
The user GUID we capture could help with push to CRM

Personas effected

Toby Lerone - Head of IT Service Management
Penn Gwynn - Head of Contact Centre
Sam Salamander - Head of Compliance/Audit and Risk

Functionality

On the current platform the Red Box Enhanced AD Metadata feature is used to capture AD metadata along with "standard" metadata for recorded communications. For each recording, the Red Box recorder will attempt to match one or more "standard" Red Box metadata fields (such as Channel Name or Extension Name) to a relevant Active Directory field, and then capture the following fields from the matched AD account.

Agent Username
Agent Email Address
Agent First Name
Agent Last Name
Agent Department
Agent Manager
Agent UID (Unique ID)

Within EA this feature has the potential to go further with our new database. This would also allow us to improve our common object model, at present it’s a bit limited due to the number and type of integrations we have.

Mapping of all AD fields is configurable and includes a regex for example to pull a username from an email address.

Add metadata to recordings populated from Active Directory

Populate a table of data with active directory information for recorded users.
1. AD metadata must be available from the start of the call
2. AD metadata capture must not have a significant performance impact on recording
3. AD metadata capture should be able to continue during a short network outage without loss of data (acceptable for it to become stale).
Use this table to map recorded items with active directory users.
Assign data from this table to recording metadata.
1. Primary use-case is to obtain email address, with consideration given to other potential useful data.
2. Configurable data field for email address, stored in agentEmailAddress database field.
3. Configurable data field for manager email address, stored in managerEmailAddress database field.
4. Configurable data field to team, stored in ADteam database field.
5. Configurable recorder side field name - could be department or team or organisation or franchise etc.
6. The core services field name should be changeable - could be department or team or organisation or franchise etc.
7. Configurable if team field is added to database and populated.
Alert raised in Health Monitoring if AD population is toggled on and download of data fails.
Audit logging if we have a call that we fail to map to an AD account
An AD user will need to be configured which has suitable permissions to traverse the AD server
The solution designed will cover both on-premise Active Directory and Azure Active Directory
The additional MetaData will be displayed in the UI within the main search grid and detail panels
We will sync all users within AD in order to keep things simple

Non Functional Requirements

Ref	Area	MoSCoW	Requirement	Comments
1	Error-handling	M	*Ease with which the system can degrade gracefully if errors occur - eg does the entire system go down and lose data if the internet goes down*	Should maintain AD records during a network outage, cache may go stale if we can't refresh.
2	Legal and Regulatory	M	*specific legal and regulatory requirements associated with the feature*	Any persistence of lookup table must be encrypted
3	Licensing		*new/amended licensing requirements associated with the feature or with introduced 3^rd party components)*
4	Localizability		*need to include localised features eg currency; date formats*
5	Performance	M	*ability to meet specific performance standards/requirements*	The lookup table will be populated from cached data at start-up and refreshed from AD both immediately after start-up and on a configurable basis – defaulting to 1 hour and with a fastest refresh rate of 2 minutes.
6	Concurrency		*Specific concurrency requirements*
7	Resilience	M	*ability to handle failure of an individual component within the system*	Should maintain AD records during a network outage, cache may go stale if we can't refresh.
8	Scalability	M	*requirements to support increasing numbers of users/concurrency without incurring significant cost*	Should support up to 100,000 users.
9	Security	M	*adherence to defined/specified customer/industry security standards*	The AD lookup table will be stored in memory with a cache written to disk to improve start-up time. The cache must be encrypted using standard AES-256 encryption. The credentials used to connect to AD must be encrypted using standard AES-256 encryption.
10	Storage		*Specific storage requirements/considerations*
11	Supportability		*ease with which Support could/need to access logs etc to diagnose a problem*
12	Test requirements	M	*ease with which the functionality could/should be supported by automated testing*	This should be end to end automatable.
13	Training		*specific training/installation/configuration documentation that is associated with this feature that need to be created/updated*
14	User Experience		*specific user experience requirements that would ensure the functionality is acceptable to customers eg can complete action within x clicks*

Current Product Documents

Future Functionality

Licensing

Feature to be licensed – feature toggled on and off

Sign Off

Simon Jolly (Unlicensed) to review initial requirements
PO - Devon Cockram (Unlicensed) to review and sign-off on requirements
QA to review and sign-off on requirements
Team Lead Sergey Shafiev (Unlicensed) to review and sign-off on requirements.

Future Platform Development