New to V10.7, a group represents a logical grouping of endpoints, including those already assigned to a user, or another group.
A queue contains resources relating to a collection of media sessions. In previous versions of Softdial Contact Center™ (SCC), 'group' was synonymous with 'queue'.
In V10.6 and earlier versions of Softdial Contact Center™, the terms queue and group have been used interchangeably. With V10.7 the term group refers to the new group functionality.
This grouping feature, allowing multiple endpoints to be managed for a single user, is a fundamental requirement to support multimedia and Automatic Session Distribution (ASD) in v10.7.
This topic describes the design changes that have been made to support group functionality and how this has been implemented.
Fig. 1 shows the relationships between the various resources in the SCC V10.7 ecosystem.
From a point of view of the core API, queues and groups are added and deleted using the same SDMP messages.
The Group Add [AG] and Group Delete [DG] messages can now be used to create and delete groups, as well as queues.
A queue differs from a group in the following ways:
A group may contain another group as a member. This aggregate behaviour allows hierarchies to be built and simplifies operation.
This logic holds true for queues as well. A queue may have groups as members, as well as endpoints. However a queue may not have other queues as members, only groups.
When configuring abstract groups, the supervisor selects from the list of endpoints and groups configured (Fig. 2):
The list of group members can contain both groups and endpoints.
It is not possible to have an endpoint address - Agent Extension (AE) - and a Group Address (GA) with the same value.
As stated above, a group and a queue can have both endpoints and groups of endpoints as members. In the Repository Editor, queue configuration now appears as shown in Fig. 3:
This shows both endpoints and groups as possible members.
The UI prevents basic recursion errors such as selecting a group as a member of itself. However, it is still possible to have say Group A containing Group B as a member and Group B can contain Group A as a member. Inside Softdial CallGem™, member lists are built using non-recursive algorithms to prevent circular relationships from causing unwanted loops.
In order to allow freedom of addressing and also resolve some issues of address conflict, addresses are now unique per tenant rather than globally. This means that the Agent Extension (AE) and Group Address (GA) parameters used in the API are now unique per tenant; in other words, 2 different tenants may have an endpoint with the same extension number, or may have 2 groups with the same address.
Internally, the collections that were global are now per tenant. This will also improve scalability.
Tenant-level routing is also supported.
Inbound routes are now determined at both tenant and landlord level.
See:
Tenant Level - Inbound Routes
Landlord Level - Inbound Routes
Operationally, Softdial CallGem™ ‘flattens’ all groups and queues into lists of endpoints. This enables a simple and deterministic view of the available resources to be maintained.
Whenever a queue or group is edited and members changed, all dependent queues and groups have their memberships recalculated.
The syslog records operational changes in membership with log entries with the prefix QUEUE: or GROUP:.
As groups are a mechanism by which many agents are allocated in configuration, Softdial CallGem™’s real-time agent management APIs follow suit.
The management APIs Move Agent [MA] and Kill Agent [KA] now take an optional Group Address (GA) parameter which is mutually exclusive with the Agent Name (AN) parameter. This allows supervisors to issue a request to move or kill a whole group of endpoints.
The behaviour of group-based move or kill differs slightly from requests for individual agents. A move or kill request will only be processed if there is not an existing request to make the endpoint unavailable of a higher precedence than the move or kill request. Unavailable precedence is the same as for V10.6.
An endpoint group may be spread across several campaigns. A kill request will forcibly log the endpoints out of the different campaigns that they are on. A move request will move all endpoints to a specific campaign, regardless of which campaign they are in.
Migration of legacy queue memberships has not been made. This will follow soon.