Jump to: navigation, search
(Created page with "= Setting Up Agent Workspace for Divisions = Category:V:HTCC:9.0.0DRAFT")
 
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
= Setting Up Agent Workspace for Divisions =
 
= Setting Up Agent Workspace for Divisions =
  
 +
{{AnchorDiv|DivisionsOverview}}
 +
==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.
 +
 +
{{NoteFormat|Currently, agents can be assigned to handle interactions for one divisions.|1}}
 +
 +
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.
 +
 +
 +
1. If an agent is a member of more than one division, how does this impact contact creation? Will the UI allow the agent to choose for which division the contact is created? If yes, do you have a screen shot of the UI? – Agent login will be blocked if he is a member of more than one division. https://genesysjira.atlassian.net/browse/WWE-1478
 +
 +
{{AnchorDiv|DivisionsTeamCommunicator}}
 +
==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.
 +
 +
{{AnchorDiv|DivisionsContactHistory}}
 +
==Contact History==
 +
In case an agent is part of a division then they can search the contact from that division and shared space. They can also access the respective contact interaction history.
 +
 +
 +
{{AnchorDiv|DivisionsContactInformation}}
 +
==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.
 +
 +
2. Is it possible for a the same contact to be in more than one division? In this case, are there two records for the same contact? If an agent is a member of two divisions and the contact is also a member of the same two divisions, how will the contact records be distinguished in contact search? –
 +
 +
a. An agent with division while creating contact WWE is sending Division’s DBID which will be stored as a DBID for the contact in UCS that can be used to distinguish the contacts.
 +
b. Agent1 (DivisionA) and Agent2 (DivisionB) can created a contact with same details but they are not the same because the contactId and DBID will be different.
 +
c. As I said above, WWE is blocking agent login in case of two divisions, so no issues with contact search in such cases.
 +
 +
Contact - Create, Read, Update, Delete (CRUD)
 +
This section explains how divisions affect contact operations in Workspace.
 +
Currently, Workspace performs the following operations on contacts:
 +
Create contact
 +
Get (Read) contact
 +
Update contact
 +
Delete contact
 +
Search contacts
 +
As part of divisions support, Workspace UI or Workspace Service will send agent's division information to UCSX when performing these operations
 +
 +
 +
The below table explains how each operation is carried out if an agent is associated with a division. 
 +
 +
Contact Operations Division's DBId added to request from UCSX division mode
 +
WWE Workspace Service strict mixed off
 +
Create Yes No Contact will be created only in the division. Contact will be created only in the division. Contact will be created in shared.
 +
Update, Read, Search and Delete No Yes Can update/read/search/delete contacts from agent's division and also from shared space. Can update/read/search/delete contacts from agent's division and also from shared space. Can update/read/search/delete contacts from only shared space.
 +
 +
 +
{{AnchorDiv|DivisionsStandardResponses}}
 +
==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
 +
        }
 +
    }
 +
}
 +
 +
 +
{{AnchorDiv|DivisionsSupervisor}}
 +
==Supervisor==
 +
 +
===My Agents view===
 +
 +
===Interactions Queues
  
 
[[Category:V:HTCC:9.0.0DRAFT]]
 
[[Category:V:HTCC:9.0.0DRAFT]]

Latest revision as of 20:01, September 12, 2022

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.

Important
Currently, agents can be assigned to handle interactions for one 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.


1. If an agent is a member of more than one division, how does this impact contact creation? Will the UI allow the agent to choose for which division the contact is created? If yes, do you have a screen shot of the UI? – Agent login will be blocked if he is a member of more than one division. https://genesysjira.atlassian.net/browse/WWE-1478

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

In case an agent is part of a division then they can search the contact from that division and shared space. They can also access the respective contact interaction 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.

2. Is it possible for a the same contact to be in more than one division? In this case, are there two records for the same contact? If an agent is a member of two divisions and the contact is also a member of the same two divisions, how will the contact records be distinguished in contact search? –

a. An agent with division while creating contact WWE is sending Division’s DBID which will be stored as a DBID for the contact in UCS that can be used to distinguish the contacts. b. Agent1 (DivisionA) and Agent2 (DivisionB) can created a contact with same details but they are not the same because the contactId and DBID will be different. c. As I said above, WWE is blocking agent login in case of two divisions, so no issues with contact search in such cases.

Contact - Create, Read, Update, Delete (CRUD) This section explains how divisions affect contact operations in Workspace. Currently, Workspace performs the following operations on contacts: Create contact Get (Read) contact Update contact Delete contact Search contacts As part of divisions support, Workspace UI or Workspace Service will send agent's division information to UCSX when performing these operations


The below table explains how each operation is carried out if an agent is associated with a division.

Contact Operations Division's DBId added to request from UCSX division mode WWE Workspace Service strict mixed off Create Yes No Contact will be created only in the division. Contact will be created only in the division. Contact will be created in shared. Update, Read, Search and Delete No Yes Can update/read/search/delete contacts from agent's division and also from shared space. Can update/read/search/delete contacts from agent's division and also from shared space. Can update/read/search/delete contacts from only shared space.


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

This page was last edited on September 12, 2022, at 20:01.
Comments or questions about this documentation? Contact us for support!