Personal Identifying Information and Eleveo WFM

Purpose of this guide: This guide describes how Personally Identifiable (PII) Data is processed by Eleveo WFM in the CLOUD.
Audience: Customer, partner, or other professional interested in knowing more about PII data in Eleveo WFM.
When: Before installation or at any time. This page is for your information only.
Next Steps: None

The following section describes the security-related aspects of Eleveo WFM and clarifies how client data is processed, what data is processed, and how data flows through the system.

About Eleveo WFM

The Eleveo WFM Importer is installed within a customer's internal network from where it can access the databases. The system then pushes the data from inside the customer's network to a dedicated WFM server.

Encryption

All communication between servers is encrypted. Eleveo WFM utilizes industry-standard encryption methods (SSL/TLS, strong symmetric-key cryptography) and uploads only very specific data to the cloud server.

Network

Eleveo Data Importers must be able to reach every data source from the machine they run on. The importer has to be able to reach the Eleveo installation and Amazon S3. All connections to the cloud are initiated from the customer network (egress only) and data sources are also located in the customer network. In most cases, Elever Data Importers should be able to work out of the box. Complex internal networks may need to be configured.

Depending on the network complexity, the following may need to be configured:

Firewalls
Databases - database may be configured to accept only connections from a specified network address
Routers/NATs and other network elements
VPNs

Transparency

Eleveo WFM Data Importers are transparent. Customers can always view its activities:

Human-readable configuration – the accessed data sources.
Eleveo WFM does not store any original data.

Data Flow

Understanding that clients have concerns about data security, Eleveo has developed all services with security best practices in mind. All communication between individual systems is encrypted. All data stored and transmitted within the systems are encrypted and are decrypted only for processing or when calculations are performed.

Data is encrypted as it travels between the client's servers and Eleveo WFM Cloud servers. Data is encrypted when transferred into the cloud and while at rest. All servers in the cloud store data in an encrypted format which limits exposure and ensures that data is secure throughout all stages of the process, including during transfer and storage.

At all times that data is sent between two servers or is being transmitted to the cloud it is encrypted using industry-standard methods of encryption.

Industry Standards

Eleveo implements a variety of industry standards for handling secure data, including, but not limited to SOC2 and PCI DSS.

Data Utilized by Eleveo WFM

Eleveo WFM requires that a variety of data types be provided for all modules to function optimally.
Data collected is used for the following purposes:

Workforce forecasting and the calculation of Agent Schedules
Monitoring Adherence to the planned schedule (Real-Time Adherence module)
and more

Below you will find a detailed description of what specific data is utilized by Eleveo WFM and how that data is grouped for analysis.

Data Sources

Eleveo WFM utilizes metadata related to agents. It does not upload any original audio/video recordings nor original text messages. Customers can opt to include custom data sources with additional data.

Data extracted and sent to the Eleveo WFM Server include the following:

Data Source	Infrastructure	Extracted Data
Eleveo Call Recording, Quality Management, Speech Recognition, Voice of the Customer, E-Learning/Training	On-premise PostgreSQL database	No data is transferred
Cisco UCCE	On-premise database	Agent-specific information is fetched via API - `teamId` `teamname` `userID` `-firstName` `-lastName` `-extension` `-alias` `-type` `-skillMap` `-primarySupervisorOf` `-secondarySupervisorOf`
Cisco UCCX	On-premise Informix database	Agent-specific information is fetched via API - `GET <scheme:hostn:port>/adminapi/teams` `reading attributes:` `teamId` `teamname` `GET <scheme:hostn:port>/adminapi/resources` `reading attributes:` `userID` `-firstName` `-lastName` `-extension` `-alias` `-type` `-skillMap` `-primarySupervisorOf` `-secondarySupervisorOf` Click here to expand... Retrieving groups by calling REST API: `GET <scheme:hostn:port>/adminapi/teams` reading attributes: teamId teamname Documentation: https://developer.cisco.com/docs/contact-center-express/#!team Retrieving all Users by calling REST API: `GET <scheme:hostn:port>/adminapi/resources` reading attributes: `userID` `firstName` `lastName` `extension` `alias` `type` `skillMap` `primarySupervisorOf` `secondarySupervisorOf` Documentation: https://developer.cisco.com/docs/contact-center-express/#!resource
CUCM AXL SOAP service	On-premise database	Additional Agent related data is sourced from the CUCM AXL SOAP service. `userid` <-----primary user email `mailid` <-----secondary user email Example of the SOAP request for User ID's (agent ID) Format of the SOAP message: `<SOAP-ENV:Envelope xmlns:SOAP-ENV="`http://schemas.xmlsoap.org/soap/envelope/`">` `<SOAP-ENV:Header />` `<SOAP-ENV:Body>` `<ns2:executeSQLQuery xmlns:ns2="`http://www.cisco.com/AXL/API/<API_VERSION>`">` `<sql>... sqlCmd</sql>` `</ns2:executeSQLQuery>` `</SOAP-ENV:Body>` `</SOAP-ENV:Envelope>` To obtain user emails, we use this SQL query: `SELECT userid, mailid, directoryuri FROM enduser WHERE userid IN (list_of_user_IDs);` `Response:` `<return>` `<row>` `<userid>userid</userId> <-----primary user email` `<mailid>mailid</mailid> <-----secondary user email` `<directoryuri>directoryuri</directoryuri>` `</row>` </return>
MS Teams	Cloud Database	Agent-specific information is fetched via API.
Zoom	Cloud Database	Agent-specific information is fetched via API.
Webex	Cloud Database	Agent-specific information is fetched via API.

Access to Data

At the API level (also used by the user interface), access is protected by token-based HTTPS authentication. Access is limited to those users with adequate permissions set in the Eleveo User Management application. Access attempts are logged and can be audited.

Data Retention

Data retention policies are set at the discretion of the customer.

Back-Up

All data sent to the Elveo WFM server (Cloud or On-Premise) can be recovered from the original systems. Disaster recovery is documented separately and is available upon request. Please contact your Eleveo representative if you require additional information.

What Data is Processed

Contact Center Employees

Data related to contact centers' employees are used for forecasting, scheduling and Real-Time Adherence:

Information Collected	Required	Purpose
`teamId`	Yes	Identifying information (required for forecasting and schedule creation)
`teamname`	Yes	Identifying information (required for forecasting and schedule creation)
`userID`	Yes	Identifying information (required for forecasting and schedule creation)
`firstName`	Yes	Identifying information (required for forecasting and schedule creation)
`lastName`	Yes	Identifying information (required for forecasting and schedule creation)
`extension`	Yes	Identifying information (required for forecasting and schedule creation)
`alias`	Yes	Identifying information (required for forecasting and schedule creation)
`type`	Yes	Identifying information (required for forecasting and schedule creation)
`skillMap`	Yes	Identifying information (required for forecasting and schedule creation)
`primarySupervisorOf`	Yes	Identifying information (required for forecasting and schedule creation)
`secondarySupervisorOf`	Yes	Identifying information (required for forecasting and schedule creation)

Contact Center Customers

Customer data is NOT collected nor used by Eleveo WFM

Attached Data

Eleveo WFM does not collect, import or use attached data. Attached data (sometimes called business data or external data) are added to segments within the Contact Center.

Access to Data

Access to data is protected by username (email) and password combinations. Each project is isolated and has its own associated users managed by Eleveo User Management.

Anonymized Data

Anonymization of data is not possible.

Technical Details

The following section provides detailed technical information about data source, mapping, configuration and transfer.

Context Diagram

Description

Cloud vrs On-Premise

NOTE- The examples provided are for cloud deployments. On-premise deployments are nearly identical in their form. The core difference is that the data is sent to a local on-premise server instead of a cloud server.

The Eleveo Data Importer pulls data about Users and Groups from either the UCCE, UCCX or CUCM system and stores them into User Management Amazon RDS database.
There is no Eleveo Data Imported for Cloud-based contact centers like WebexCC, Zoom, or MS Teams. Eleveo can access the data directly e.g. via API or in case of user sync - via a connection to the Active Directory.
The Eleveo Data Importer pulls data about calls - queues (queue's IDs) and the number of calls performed within those queues and their average handling times aggregated to 15 minutes intervals - and stores them into WFM's Amazon RDS database.
The Eleveo Data Importer pulls a distinct list of Agent's statuses (including Reason Codes) from Finesse using the Finesse API needed for schedule adherence configuration.
The Eleveo Data Importer pulls Agent's statuses (including Reason Codes) from UCCX/UCCE DB needed for the calculation of schedule adherence.
The Eleveo CTI Events Importer pulls Agent State events from Cisco CTI servers, in real-time, into Eleveo.
Users are synchronized from Eleveo User Management to WFM.
Prometheus scrapes various application metrics and sends them to the Grafana monitoring tool.
Eleveo Support monitors applications and receives alerts in case of any system issues.
The user (Agent, Supervisor) accesses the WFM application using SSO while being authenticated against UCCX/UCCE/CUCM.

Integration with UCCX

Users and Groups import

The following table describes the configuration of UCCX and CUCM Connection for API communication.

Parameter	Supported values	Example/default values	Is change required?	Description
uccx section – the configuration of UCCX connection
scheme	string	"https"	Fill in your settings	protocol that should be used (http, https)
port	integer	443	Fill in your settings	port on which UCCX is running
host	string	"uccx.test.com"	Fill in your settings	name or IP address of the UCCX server
username	string	"ccxadmin"	Fill in your settings	UCCX administrator username
password	string	"12345"	Fill in your settings	UCCX administrator password
importedGroups	string	"Group1, Group2"	Fill in your settings	groups which should be imported, read more in the box below the table
cucm section – the configuration of the database against which imported users will be authenticated
scheme	string	"https"	Fill in your settings	protocol that should be used (http, https)
port	integer	443	Fill in your settings	port on which CUCM is running
host	string	"cucm.test.com"	Fill in your settings	hostname or IP address of the server where the database is located
username	string	"ccmadmin"	Fill in your settings	database username
password	string	"12345"	Fill in your settings	database user password
version	string	"11.x"	Fill in your settings	version of CUCM

Data Mapping from the UCCX Database

The following tables describe how data imported from UCCX is mapped to the User Management database. In the case of UCCX, the database is not accessed directly but via API. Therefore only UCCX API objects are mentioned and database tables are omitted.

UCCX API Object	UCCX API Object Attribute	User Management Table	User Management Table Column	Notes
resource	userId	user_attribute	value (key: agentId)	Mapped as username and agentId in User Management.
team	teamname	keycloak_group	name
	teamId	group_attribute	value (key: externalGroupId)
	userId	user_entity	username	Mapped as username and agentId in User Management.
	firstName	user_entity	first_name
	lastName	user_entity	last_name
	extension	user_attribute	value (key: phoneExtension)
	teamId	user_group_membership
	primarySupervisorOf	user_role_mapping		Data Importer application re-maps client role names, configuration is in application.properties in roleEquivalents section. Mapped client roles in User Management must exist.
	secondarySupervisorIf	user_role_mapping		Data Importer application re-maps client role names, configuration is in application.properties in roleEquivalents section. Mapped client roles in User Management must exist.

Note that in the case of an import from UCCX, the email attribute is fetched from CUCM AXL API:

UCCX AXL Table	CUCM AXL API Object Attribute	User Management Table	User Management Table Column
enduser	mailid	user_entity	email
	directoryuri	user_attribute	value (key: secondaryEmail

Cloud Architecture Diagrams

The following diagrams are intended to show the interconnections between the various components of the Eleveo WFM Data Importers. The diagrams are not exhaustive in detail and are intended to be informative only.

Eleveo WFM Architecture for UCCX

Eleveo WFM Architecture for UCCE

Key Information about the Architecture:

Eleveo deployed in AWS cloud utilizes a multi-zone deployment, meaning, that the installation spans across three availability zones (N. Virginia or EU Frankfurt). This is designed to ensure high availability in case of a single failure.
Importers can be deployed in multiple data centers.
A Virtual Machine (usually Replay Server) contains the Eleveo data importers running in Kubernetes in each DC. Each is connected to their respective UCCX/UCCE instances.
Connections from the Customers On-Premise server are egress only through the internet towards the Eleveo Application Load Balancer provided on the path http://<tenant>.myeleveo.com/ DNS record for both user and application access.
For Cloud deployments, the Eleveo Monitoring and Alerting (as well as Eleveo Service and Support maintenance), are handled outside of the Customer On-Premise servers.