Technical Details and Limitations
Import From UCCE
Data Mappings
The following tables describe how data imported from UCCE is mapped to the User Management database. Unique identifiers are marked in yellow.
UCCE Table View | UCCE Table column | UCCE API Object | UCCE API Object Attribute | User Management Table | User Management Table Column | Notes |
|---|---|---|---|---|---|---|
Agent | PeripheralNumber | agent | agentId | user_attribute | value (key: agentId) | |
SupervisorAgent | supervisor (boolean, 1=SUPERVISOR, 0 = AGENT) | 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. | |||
Person | FirstName | agent.person | firstname | user_entity | first_name | |
LastName | lastName | last_name | ||||
LoginName | userName | username | ||||
LoginEnabled | loginEnabled | enabled | ||||
Agent_Team | EnterpriseName | agent.agentTeam | name | keycloak_group | name | |
AgentTeamId | refURL (parsed from) | group_attribute | value (key: externalGroupId) | |||
Agent_Team_Member | agent.agentTeam | user_group_membership | ||||
Agent_Team_Supervisor | agent.supervisorTeams | user_supervisor_membership |
Changing User's Details
A change of the user's details in UCCE (for example when women change their surname/username) is handled in the following way:
In the case that a username stays the same (for example only a surname is changed), this information of the existing user is updated in User Management during the synchronization process.
In the case that a username is changed, it cannot be mapped to the existing user in User Management and the user's details cannot be updated. The reason is that User Management identifies users based on a username (in both cases: when a user is imported from UCCE, or when a user is imported from UCCX). This case can be handled in the following way:
During the synchronization process, a new user with a new username is created in User Management and the 'old' user in User Management is disabled.
Attributes added on the Attributes tab will not be overwritten or removed during the next synchronization process.
Disabling, Deleting, Re-Enabling and Re-Creating Users
Disabling, re-enabling and deleting users from UCCE is handled in the following way:
A user disabled in UCCE will also be disabled in User Management.
If a user is re-enabled in UCCE, this user will be re-enabled in User Management and all mappings (roles assigned, teams membership) will be set in the same way as they were set before.
A user deleted in UCCE will be disabled in User Management.
Re-creating a user who was already deleted in UCCE is handled in the following way:
If a user who was imported from UCCE is deleted in User Management and then added back manually (with the same username), this manually created user will remain in User Management and will not be synchronized with UCCE or imported again. The reason for that is that usernames need to be unique. In case that this manually added user is later deleted in User Management, the user with the same username will be imported again from UCCE during the next synchronization.
If a user with the same username and the same AgentID value is added again in UCCE, this user will be re-enabled in User Management after the next synchronization process and all mappings (roles assigned, teams membership) will be set in the same way as they were set before.
If a user with the same username but with a different AgentID value is added in UCCE, it is not possible to import this user to User Management (or to re-enable the disabled user with the same username).
Teams and Team Membership
Any changes to the teams configured in User Management are handled in the following way:
If a subteam is manually added by an admin to a team that was imported from UCCE, it will be deleted. Teams that exist in UCCE are compared with teams (and subteams) that exist in User Management (and are from the same User Federation). If User Management contains any team/subteam which don't exist in UCCE, these teams will be removed.
If the team that was imported from UCCE was renamed in User Management, the name will be changed back. Any manual changes of the team names will be overwritten so that they match those in UCCE.
Membership in a team is handled in the following way:
If a user is not a member of any team in UCCE, he/she will not be imported to User Management.
If a user is added as a member to a team in UCCE, he/she will be also added to a team in User Management.
If a user is being unassigned from a team in UCCE, he/she will be also unassigned from a team in User Management.
If a user imported from UCCE is being manually added as a member to a team that was manually created in User Management, this membership will not be removed during the next synchronization process (the user will stay in this team).
If a user imported from UCCE is being manually added as a member to a team that was also imported from UCCE, this membership will not be removed during the next synchronization process (the user will stay in this team).
Users can be moved between teams in UCCE. After the next synchronization, these users will also be moved in User Management - they will then belong to the same teams as in UCCE (even if the structure of teams was modified in UM). The order of teams in UM is not affected by the synchronization.
Setting a team as main is handled in the following way:
If the main team is changed from A to B manually in User Management, and both teams exist in UCCE, this change will not be overwritten during the next synchronization process. However, in the case that team B is local only (it doesn't exist in UCCE), this change will be overwritten during the next synchronization process.
If there is a need to rename imported team in the upstream system, please proceed carefully!
If the teams imported from a call center platform are limited using the importedTeams parameter, there is a possibility that actions taken in a wrong order result into deletion of a team and creation of a new team instead of renaming. Supervisors will then lose the possibility to see old calls.
Please check running configuration of UCCE User Data Importers and if the importedTeams parameter is used, see workaround in the section Renaming Teams Workflow.
'Can Manage' Assignment
The assignment of teams that a user with the Supervisor/Teamlead role can manage is handled in the following way:
If a user with the Supervisor/Teamlead role has no teams assigned in UCCE, he/she will be imported to User Management also without any teams assigned.
A team assigned to a user in UCCE will be also assigned in User Management during the synchronization process.
If a team is being unassigned from a user in UCCE, it will be also unassigned in User Management.
If a team was assigned to a user manually from within the User Management UI, whether this user and team were imported or created manually, this change will not be overwritten during the next synchronization.
If a team was assigned to a user automatically and then this assignment is modified manually (a team is unassigned from a user), this change will be reverted and a team will be automatically assigned to a user during the next synchronization.
It is not possible to demote a Supervisor/Teamlead to Agent in UCCE if any teams are assigned to this user. It is necessary to first unassign that user's teams and then change the role. As a result, the user will have teams unassigned and will change their role in User Management during the synchronization process.
Import From UCCX
Data Mappings
The following tables describe how data imported from UCCX is mapped to the User Management database. The unique identifiers are marked in yellow. 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 |
|---|---|---|---|---|
team | teamname | keycloak_group | name | |
teamId | group_attribute | value (key: externalGroupId) | ||
resource | userId | user_attribute | value (key: agentId) | Mapped as username and agentId in User Management. |
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 | |
directoryuri | user_attribute | value (key: secondaryEmail |
Changing User's Details
A change of the user's details in UCCX (for example when women change their surname/username) is handled in the following way:
In the case that their username stays the same (for example only their surname is changed), this information of the existing user is updated in User Management during the synchronization process.
In the case that their username is changed, it cannot be mapped to the existing user in User Management and the user's details cannot be updated. The reason is that User Management identifies users based on a username (in both cases: when a user is imported from UCCE, or when a user is imported from UCCX). This case can be handled in the following way:
During the synchronization process, a new user with a new username is created in User Management and the 'old' user in User Management is disabled.
Attributes added on the Attributes tab will not be overwritten or removed during the next synchronization process.
Disabling, Deleting, Re-Enabling and Re-Creating Users
Disabling, re-enabling and deleting users from UCCX is handled in the following way:
A user disabled in UCCX will also be disabled in User Management.
If a user is re-enabled in UCCX, this user will be re-enabled in User Management and roles assignment will be set in the same way as it was set before. However, re-enabled users are members of a default UCCX team with ID 1, so as a result, after synchronization the user will be a member of the team with ID 1 also in User Management.
A user deleted in UCCX will be disabled in User Management.
In case the IPCC number of a user in CUCM was deleted, this user is also marked as deleted in UCCX. The user will also be disabled in User Management.
If a user who was imported from UCCX is deleted in User Management and then added back manually (with the same username), this manually created user will remain in User Management and will not be synchronized with UCCX or imported again. The reason for that is that usernames need to be unique. In case that this manually added user is later deleted in User Management, the user with the same username will be imported again from UCCX during the next synchronization.
Re-creating a user who was already deleted in UCCX is handled in the following way:
If the user with the same username is added again in UCCX, this user will have the same AgentID as before (because these values are always equal for users imported from UCCX). As a result, this user will be re-enabled in User Management after the next synchronization process and roles assignment will be set in the same way as it was set before. However, re-enabled users are members of a default UCCX team with ID 1, so as a result, after synchronization this user will be a member of the team with ID 1 also in User Management.
If there is a need to use the same username for a different person, which means that this user should be re-created in User Management rather than re-enabled, rename the old user in User Management (so that their username is different) and proceed with the import of the new user.
Teams and Team Membership
Any changes to the teams configured in User Management are handled in the following way:
If a subteam is manually added by an admin to a team that was imported from UCCX, it will be deleted. Teams that exist in UCCX are compared with teams (and subteam) that exist in User Management (and are from the same User Federation). If User Management contains any teams/subteams which don't exist in UCCX, these teams will be removed.
If the team that was imported from UCCX was renamed in User Management, the name will be changed back. Any manual changes of the team names will be overwritten so that they match those in UCCX.
Membership in a team is handled in the following way:
If a user is not a member of any team in UCCX, he/she will not be imported to User Management.
If a user is added as a member to a team in UCCX, he/she will be also added to a team in User Management.
If a user is being unassigned from a team in UCCX, he/she will be also unassigned from a team in User Management.
If a user imported from UCCX is being manually added as a member to a team that was manually created in User Management, this membership will not be removed during the next synchronization process (the user will stay in this team).
If a user imported from UCCX is being manually added as a member to a team that was also imported from UCCX, this membership will not be removed during the next synchronization process (the user will stay in this team).
Users can be moved between teams in UCCX. After the next synchronization, these users will be also moved to User Management - they will then belong to the same teams as in UCCX (even if the structure of teams was modified in UM). The order of teams in UM is not affected by the synchronization.
Setting a team as a main team is handled in the following way:
If the main team is changed from A to B manually in User Management, and both teams exist in UCCX, this change will not be overwritten during the next synchronization process. However, in the case that team B is local only (it doesn't exist in UCCX), this change will be overwritten during the next synchronization process.
If there is a need to rename imported team in the upstream system, please proceed carefully!
If the teams imported from a call center platform are limited using the importedTeams parameter, there is a possibility that actions taken in a wrong order result into deletion of a team and creation of a new team instead of renaming. Supervisors will then lose the possibility to see old calls.
Please check running configuration of UCCX User Data Importers and if the importedTeams parameter is used, see workaround in the section Renaming Teams Workflow.
'Can Manage' Assignment
The assignment of teams that a user with the Supervisor/Teamlead role can manage is handled in the following way:
If a user with the Supervisor/Teamlead role has no teams assigned in UCCX, he/she will be imported to User Management without any teams assigned. If a team is assigned manually to a Supervisor and then this user is synced against UCCX, the manual changes will be lost.
The teams assigned to a user in UCCX will also be assigned in User Management during the synchronization process.
If a teams is being unassigned from a user in UCCX, it will also be unassigned in User Management.
It is not possible to degrade a user from a Supervisor/Teamlead to Agent in UCCX if any teams are assigned to this user. It is needed to first unassign the teams and then change the role. As a result, the user will have teams unassigned and will change their role in User Management during the synchronization process.
Import From CUCM
Data Mappings
The following tables describe how data imported from CUCM is mapped to the User Management database. CUCM User Data Importer loads data directly from AXL API, therefore there is no information about roles and teams.
UCCX AXL Table | CUCM AXL API Object Attribute | User Management Table | User Management Table Column | Notes |
|---|---|---|---|---|
enduser | userid | user_entity | username | |
userid | user_attribute | value (key:agentId) | ||
firstname | user_entity | first_name | ||
lastname | user_entity | last_name | ||
mailid | user_entity | |||
directoryuri | user_attribute | value (key: secondaryEmail) | ||
numplan | dnorpattern | user_attribute | value (key: phoneExtension) | Multiple values can be mapped to User Management |
dirgroup | name | keycloak_group | name | Group name in KC can be overridden by groupEquivalent config property |
pkid | group_attribute | value (key:externalGroupId) |
Changing User's Details
A change of the user's details in CUCM (for example when women change their surname/username) is handled in the following way:
In the case that their username stays the same (for example only their surname is changed), this information of the existing user is updated in User Management during the synchronization process.
In the case that their username is changed, it cannot be mapped to the existing user in User Management and the user's details cannot be updated. The reason is that User Management identifies users based on a username. This case can be handled in the following way:
During the synchronization process, a new user with a new username is created in User Management and the 'old' user in User Management is disabled.
Attributes added on the Attributes tab will not be overwritten or removed during the next synchronization process, unless the attribute name is one of the reserved keywords, such as phoneExtension or secondaryEmail.
Disabling, Deleting, Re-Enabling and Re-Creating Users
Disabling, re-enabling and deleting users from CUCM is handled in the following way:
A user disabled in CUCM will also be disabled in User Management.
If a user is re-enabled in CUCM, this user will be re-enabled in User Management and roles assignment will be set in the same way as it was set before.
A user deleted in CUCM will be disabled in User Management.
If a user who was imported from CUCM is deleted in User Management and then added back manually (with the same username), this manually created user will remain in User Management and will not be synchronized with CUCM or imported again. The reason for that is that usernames need to be unique. In case that this manually added user is later deleted in User Management, the user with the same username will be imported again from CUCM during the next synchronization.
Re-creating a user who was already deleted in CUCM is handled in the following way:
If the user with the same username is added again in CUCM, this user will have the same AgentID as before (because these values are always equal for users imported from CUCM). As a result, this user will be re-enabled in User Management after the next synchronization process and roles assignment will be set in the same way as it was set before.
If there is a need to use the same username for a different person, which means that this user should be re-created in User Management rather than re-enabled, rename the old user in User Management (so that their username is different) and proceed with the import of the new user.
Teams and Team Membership
Membership in a team is handled in the following way:
Only members of a specific team in CUCM are imported to User Management, as configured in Data Importer. By default, a team with the same name is added in User Management and users become its members. The name of the teamin User Management can be changed by adding a groupEquivalent parameter to the YAML file.
If a user imported from CUCM is being manually added as a member to a team that was manually created in User Management, this membership will not be removed during the next synchronization process (the user will stay in this team).
It is not possible to import multiple teams and their members from the CUCM server.
'Can Manage' Assignment
In CUCM there is no assignment of teams that a user with the Supervisor/Teamlead role can manage, therefore this information is not synchronized with User Management.
Import From Multiple Source Servers
UCCE, UCCX and CUCM User Data Importers are capable to import users from multiple different source servers of same type, for example two completely different deployments of UCCE when recordings are collocated on same replay server. Please contact Eleveo SaS if need to import users from several sources.
If the same user (with the same username) is present on more than one UCCE/X or CUCM server, this user will be synchronized only once (the first user that comes will be imported to User Management). The same user coming from the next sources will be ignored. The order of sources and the periodicity of an import can be modified by using the cron expression in Scheduler.
Limitations
The following are limitations of the import:
It is not possible to import the same user twice from two different UCCE servers, two different UCCX or from two different CUCM servers. During the second import, the original user will not be updated, because of the different sourceId, but will also not be imported as a new user (the username is already in use).
If a user is removed from the UCCE/X or CUCM server and then the same user (with the same userId on the source server’s side) is added again on another server of the same type, this user will not be re-enabled in User Management. To re-enable the user, the sourceId attribute (on the Attribute tab in user's properties) should be manually changed to a new value which is the sourceId of the second source server (it can be found in the yaml configuration file of the User Data Importer). Additionally, team membership should also be corrected manually. It means that the user should be removed from teams from the first source server, and then (optionally) added to teams from the second source server. If a user is not added to new teams, this membership will be created during the next synchronization process. The source of a team is visible in the team path (for example, in the path
/cucm02/team01,cucm02is the sourceId that can be found in the yaml configuration).
Renaming Teams Workflow
This applies to UCCE and UCCX import only!
If you need to rename the team on the call center platform, follow the steps:
scale down the respective importer to 0 instances, no users will be able to log in
update the team name in the upstream system
update the importedTeams configuration section of the importer application
when the configuration is saved, the pod will scale back to 1 and continue with the new configuration and update the group accordingly, user will be able to log in again.