Contents
Setting Up Agent Workspace for Divisions
Overview
Genesys supports the separation of contact centers into divisions or lines of business. Some organizations divide the company across different business units, lines of business, countries, office locations, and so on. This is known as Line of Business (LOB) Separation. Genesys calls these different organizational groups divisions.
Divisions enable your organization to separate contact data so that it can only be accessed by agents belonging to the associated division. In organizations that do not employ divisions, the organization's contact data is accessible by all agents.
The following are examples of the types of contact center objects that can be isolated in a division:
- Agents
- Agent Groups
- Interaction Queues
- Real-time and historical reports
- Contact Directory information
- Contact History information
- Skills
- Interactions
- Interaction recordings
- Workforce Management data
- Outbound campaign data
- Personally Identifiable Information rules
In organizations that use divisions, agents in the same division are all a part of the same access group. If an agent or supervisor is in a division, their access to the organization is restricted to what is available to their division.
Team Communicator
When Divisions is implemented in your organization, Team Communicator searches only for internal targets and external contacts that are assigned to an agent's division. If an agent enters information for a contact or an internal target that is not assigned to their division, Team Communicator displays 0 matching Internal Targets and 0 matching Contacts. Agents may only transfer calls, create call conferences, and start consultation calls with internal targets that are in their division.
With Divisions, Team Communicator searches return results for the following internal targets for which the agent's division has read access:
- Internal Targets
- Agent
- Agent Group
- Skill
- Routing Point
- Interaction Queue
- External Targets
- Contact (the Team Communicator contact search returns contacts from the agent's division and also from contacts who are not restricted to a division)
An agent in a division can only transfer to, conference with , or consult with internal targets in the same division.
WWE has the 2 following options to reduce the scope of presented for this type of targets:
teamcommunicator.permissions.agent.exclude-from-agent-groups
teamcommunicator.permissions.agent.restrict-to-agent-groups
Agent Groups
WWE has the 2 following options to reduce the scope of presented for this type of targets:
permissions.agent-group.exclude
permissions.agent-group.restrict
Routing Points
WWE doesn't have options to manage the scope for this type of target. WWE should introduce options similar to agent groups.
The end point "/workspace/v3/targets" provides parameters to exclude/restict search result only according to agent groups.
Not according to routing points, interaction queues nor skills.
(see https://jira.genesys.com/browse/GAPI-26753)
Interaction Queues
WWE doesn't have options to manage the scope for this type of target. WWE should introduce options similar to agent groups.
The end point "/workspace/v3/targets" provides parameters to exclude/restict search result only according to agent groups.
Not according to routing points, interaction queues nor skills.
(see https://jira.genesys.com/browse/GAPI-26753)
Skills
WWE doesn't have options to manage the scope for this type of target. WWE should introduce options similar to agent groups.
The end point "/workspace/v3/targets" provides parameters to exclude/restict search result only according to agent groups.
Not according to routing points, interaction queues nor skills.
(see https://jira.genesys.com/browse/GAPI-26753)
Contacts
WWE allows to specify the list of favorites based on the following option:
teamcommunicator.corporate-favorites
Like most of WWE options, this options can be set at all levels(application, agent group, agent).
Favorites
The list of presented favorites can be managed at different levels;
Cluster
Agent Groups
Agents
If there is an set an agent group representing a division, the option teamcommunicator.corporate-favorites must be set on it
Microsoft Teams
Filtering the search Some options have been created, allowing the Search for Teams users to be restricted, based on Azure AD group membership and/or Azure AD profile attributes.
teamcommunicator.permissions.ms-teams.restrict-to-ad-group-id With this option could be specified in what group of users should be made search. This info contains in Azure Active Directory → Groups → Group Overview, field "Object Id"
For example, if search should be done in group with Object Id = "1925b245-c54f-4165-f16d1b12658a", as on screenshot, value in configuration should be
"teamcommunicator.permissions.ms-teams.restrict-to-ad-group-id" = "1925b245-c54f-4165-f16d1b12658a" If this option in configuration is empty or doesn't exist, search will be done in all users contains in Azure Active Directory.
Contact History
Contact creation, search, update, and delete
interaction does not have GRECORD_PARTITIONS/G_DIVISIONS attached data, then use the Division (access group) name(s) associated with the user. When WWE is creating a contact, it must pass the Division associated with the interaction if a Division is not present on the interaction, the Division associated with the agent should be used.
Standard Responses
standard responses and knowledge - this should be filter based on interactions (GRECORD_PARTITIONS/G_DIVISIONS value) being processed at the time using the UCSX API with Division name(s) or other product APIs.
Standard Response An agent can view and use those standard responses that are from his division and those from the shared space. They can't get standard response belongs to different division.
Use Cases
Non Division agent can get SR from shared space. Division A agent can get SR from Division A and shared space. Division B agent can get SR from Division B and shared space. Division A agent cannot get SR from Division B. Non Division agent cannot get SR from either DivisionA or DivisionB. Creating Standard Response in UCSX At first, we need to create a root category after that we can to add a SR to that. Knowledge manager will not support to add response to UCSX. UCSX has APIs to add 'root category' and 'SR'.
Category and SR should have same division. For details see CMX 0.2 REST API Sample postman collection to add category and responses with division.
Add Category:
'theId' should be 16 digit. Division dbId should be in request body. Add response:
'categoryId' should be 16 digit. Division dbId should be in request header. If you want to add category/response into shared space, use division dbId as '0'.
Add Category host:8094/ucs/v3/rest/request/add-category-root Collapse source {
"data": {
"theId": "Root1228Root1231",
"theName": "RootCategory1223",
"tenantId": 1,
"language": "Eng",
"status": "Approved",
"ownerId": 1,
"type": 0,
"description": "string"
}
} Add Standard Response host:8094/ucs/v3/rest/request/add-standard-response Collapse source {
"data": {
"standardResponse": {
"categoryId": "0000000000000003",
"ackUsageType": "Automatic",
"agentDesktopUsageType": "Automatic",
"autoRespUsageType": "Automatic",
"emailOutUsageType": "Automatic",
"voiceAutoRespUsageType": "Automatic",
"wssusageType": "Not Used",
"ownerId": 2,
"status": "Approved",
"body": "Division A STDR - Offer3",
"theName": "Offer3",
"tenantId": 1
}
}
}
Supervisor
My Agents view
===Interactions Queues