3.5.02 Release Notes  


New Dashboard

FEATURE

A new lean and easy to configure Dashboard has been added to the Stratus Agent features, including several initial Widgets.

  • This new Dashboard is flexible to use, can be set public to all users and allows to re-assign ownership to other Stratus Agent users.
  • Lot's of powerful filtering and grouping options to show only the data you need.
  • Supports a huge variety of KPI and Metrics be showcased specialized widgets (Overall, External, Inbound, Outbound, Conversation As, Other)
  • Features a modernized layout, colors and many usability improvements over the classic Web FrontEnd.
  • Can be referred to via link and made header-less via paramete to better integrate in larger cockpit and status management setups.

(smile) Please note that the Dashboard does not (yet) fully replace all Web FrontEnd features. Instead it will gradually expand with re-interpretations of existing functionality as well as new features - all packed into a much more modern and lean design. We appreciate your feedback to make the Dashboard the best it can be!

(lightbulb) Both the Dashboard and Web Frontend can still be installed and used in parallel if you want to try the new options in parallel.

The new Dashboard in Edit-Mode

How to use

Preconditions for Viewing / Editing Dashboards

  • To View the Frontend and its Dashboards, the Web > Agent or Web Service role needs to be granted within Role Based Access - RBAC to either a Supervisor or Agent user. Different Dashboard Widgets are made available based on the role given.
  • Only a System Administrator or the current board owner can edit Dashboard properties. You can change ownership as described in the Dashboard Properties → Ownership chapters. 
  • Supervisors additionally can set a board to "Public" to the designated Organization Unit. This is also configured is also set in the Dashboard Properties.

"Agent States Availability Chart" widget

FEATURE

Shows an aggregation of available (signed-in) agents with an "On-Duty" profile selected. 

  • Shows agent states "mapped" to one or more services, e.g. How many agents are currently selectable for service(s) X Y and Z combined
  • "Replaces" the "Distribution Group Status" from our previous Frontend
  • Aggregates Services by distribution group. If not possible "subsequent" services from the same distribution group will be offered.
  • Service selection depending on the OU by the current user.
  • You can set which Distribution Policy profile should be considered for the Agent selection
    • 1st Profile
    • All Profiles (default)

Agent Availability Chart
(tick) RBAC: User needs to be of the "Agent > Supervisor" group to see and use this widget.

Service Groups - Custom Filters across multiple OU

FEATURE 

With "Service Groups" we allow any authenticated Dashboard user to define custom groups as a type of "Custom Filter Set" to apply to Dashboard widgets. These groups can break out of the usual "Organization Unit" visibility approach, allow to share data sets that would be otherwise inaccessible to other Dashboard users.

Service Group shown to an anonymous user

"Service Group" expand the traditional filter method on Dashboard Widgets such as:

  • Service KPI
  • Service KPI Chart
  • Service KPI Tabular
  • Agent States Availability Chart

(tick) How to enable: Refer the Dashboard "Settings" menu entry which allows access to "Service Group Management" for each individual user.


(info) Visit the Service Groups page for further details, concepts and usage.

"Service KPI Tabular" widget

FEATURE

The new "Service KPI Tabular" widget displays service KPI's aggregated by "→ Service Groups" in a tabular view.

Service KPI Tabular

RBAC Permissions

User with the following Roles can see data for OU's where they have this role

  • Supervisor > Web > Service
  • Agent > Web > Service

The widget can be added to Public Dashboards including anonymous access. Widgets are not removed from dashboard if user has no access.

Features

This widget makes use of Service Groups as defined by the group (filter) owner. (info) See → "Service Groups" for more info.

The user may extend the use by applying:

  • Additional filters are applied as on the other Service KPI widgets.
  • Thresholds are same as for similar widgets (e.g. "OU Service KPI Tabular")

How Data is displayed

  • On the first level this widget shows only services in the service group and aggregates selected KPIs aggregated for that group.
    • On the second level this widget shows the individual services in that service group and the selected individual KPIs.

KPI Filters with threshold criteria

FEATURE

KPI based threshold filters
  • Additional KPI filters may now be applied to Service KPI widgets. Services which fulfill the filter criteria(s) are used to calculate the KPI
  • Thresholds may be used to signal or color-code changes to the KPI values

Dashboard UI Changes


Agent Supervision View in the Main Menu

FEATURE

Agent Management View

As a brand-new addition to the Frontend the Agent Supervision view lists all Agents for the currently logged-in Supervisor in a separate page:

  • Offers direct access to Agent profiles, status and modalities.
  • Clear and direct access to Agent Supervision.
  • Quick access to individual Agent Trait pages (Leads to Tab "Agent Traits")
  • Supports tile design (default) and table design for more details.
  • Powerful filter options to quickly access only a subset of Agents .
  • Less-frequent information (SIP, Telephone number, etc.) made available via mouse-hover to keep the view clean.
"Agents Supervision" widget

FEATURE

Alongside with the new Agent Supervision view in the main menu we also provide the "Agent Supervision" Widget to any user's individual Dashboard:

  • Offers the same functionality as used by default on the "Agent Supervision" view (located on the Dashboard main menu).
  • Widget and Supervision view offer the same individual settings, including card/table view style, columns, filters and other widget options.
  • A supervision indicator is provided in any view (including agents NOT directly supervised by the currently logged-in user).

(tick) RBAC: User needs to be of the "Agent > Supervisor" group to see and use this widget or the view.

Agent Supervision in a tabular view

(lightbulb) Note that changes to Agents (including Supervision) are tied to a 2-staged confirm dialogue. Dashboard controls are disabled during Widget edit-mode to prevent accidental clicks.

Supervision for "Conversation as" and Callback (Outbound)

FEATURE

As a much-requested feature, Supervision is now possible for both "Conversation as" and "Callback (Outbound)" tasks. 

(info) We also revised the Outbound / Callback Task Configuration, moving everything into a new Settings tab.

How to use

Use "Supervise" on any "Conversation as" and "Callback" type conversations directly via the "Live Sessions"/"Live Agent" View (or any related Supervison-type Widgets).

Notes

  • Supervisors of Agents tagged for supervision will also receive the Agent's individual "Outbound" Conversations and Callback tasks.
  • Sessions are eligible for supervision starting when a customer is successfully connected to the conversation.
  • Reporting shall include "outbound" related sessions in the same way as treats does inbound sessions.

Dashboard - Customer Journey

FEATURE

Customer Journey

The customer journey feature makes a return from our classic Frontend, now featuring a fresh new look directly included in the Dashboard

  • Allows access to ongoing conversations, with data refresh
  • Search and filter functionality

Reporting - Support of Paginated BI Reports

FEATURE

The Dashboard reporting feature will automatically display an embedded BI-Report with the latest service and agent metrics.

Prerequisites

To use this feature the following prerequisites must be met:

  1. The user that grants access to BI Reports via the Dashboard must have a Power BI Pro account.
  2. For Azure Reporting Data access all future reporting users must be considered (e.g. as an Azure AD group). 
  3. The owner of the BI Report must upload the BI report into the Azure Cloud and generate a shared BI Report URL.
    (tick) A shared BI Report access URL is generated as result of this process. This URL is required to be used in Stratus Agent Configuration > Reporting section.
  4. Within Stratus Agent Role Based Access > Supervisor > Reporting > Customer / Agent / Service rights need to be granted for access to Reporting. 
    (warning) These users must match with the AD Group specified in Step 2. BI Reports will apply Row Level Security based on these user's roles.
  5. We need to configure a few details on Stratus Agent based on your hosted BI environments.
  6. Afterwards your reporting user(s) should see the extra tab in the Dashboard.

(info) Note that this is a very tl;dr type of checklist. For a full walkthrough on this process - including a discussion on your Reporting needs - get in contact with Support:

E-Mail:support@luware.com
Web:https://luware.com/en/contact/
Skype:sip:support@luware.com
Support Hotline CH+41 58 404 2807
Support Hotline DE+49 711 8998 9621
Support Hotline UK+44 20 3300 2751

Profile Management while Offline

IMPROVEMENT

For both the Frontend as well as the New Dashboard an Agent's duty profile can be changed even while offline/ none:

  • Supervisors get additional controls via Widget to change profiles of (supervised) Agents.
  • Agents can change their profile directly via the user menu next to the Logout button.

Profile Management Controls

Related improvement

Because not all users switch profiles via Agent Assistant we allowed to change profiles even if the user is considered "Offline" or "None". This may cause Reporting issues as profile changes were not tracked for "offline" users.

We therefore continue reporting of profile changes:

  • ... independent of the current "LyncState" of the user. 
  • .... when user is doing the changes offline.

API Changes


API - Introduce CCTX and Parameters for Tasks

FEATURE

The API now offers a possibility to trigger Conversation Context (CCTX) directly through the task API. By doing so, no ongoing/incoming call or workflow is triggered.

  • Add optional parameter "ConversationContextIDs" to the AddTaskParameters in  /v1.0/tasks
    • Takes a list (Array) of GUID's
    • Accepts internal IDs (Guid) of assigned Conversation Contexts (Context -> Set Conversation Context) to selected service
    • Task has to be "DistributeToAgent"=true: true
  • Add optional parameter "ContextParameters" to the AddTaskParameters in  /v1.0/tasks
    • Accepts a list of parameters defined by "Name" and "Value"
    • Parameter have to be configured for the service selected (Context -> Set Parameter) and they are not allowed to be system parameters
    • Task has to be "DistributeToAgent"=true
  • Add new GET-Method to list the configured context information for a service:
    • /v1.0/services/{serviceIdentifier}/context
    • RBAC: Execute for: TasksManage, TasksReadonly, ServicesReadonly
    • Return values:
      • Set parameters for service in question: Name
      • Set conversation contexts for service in Question: ID (Guid), Name

How to use

Example Use Case: A new incoming Email (Zendesk Mail) creates a Zendesk ticket, which then triggers the distribution through the task API.

(warning) Limitation: Does not show additional context information to the Agent right now. The API allows only to define a caller which then is shown in the header of the LUCIE toast.

API - Share Context for Agents on Consultative Transfer

FEATURE

Using the API it is now possible during a consultative transfer to share and open Conversation Context for the target Agent as well.

How to use

Preconditions

  • Requires the API to be installed and running
  • Sharing must be enabled Queue Service > Settings > Context Tab "Allow Share Context Information on Consultation Transfer"

  1. Call Service →  Agent1 accepts the call
  2. Get task id for the Service via API (/v1.0/services/{serviceIdentifier}/tasks)
  3. Generate a consultative call to Agent2 for the current session (/v1.0/tasks/{taskIdentifier}/consultationCall)
  4. Trigger a consultative transfer (/v1.0/tasks/{taskIdentifier}/consultationCall/transfer)


API - Support for Non-Blocking Tasks

FEATURE

Added a new feature to create "non-blocking" external tasks for Agents. A new parameter "BlockAgent":"true" was added to the /v1.0/tasks within the API documentation. Default: true.

Configuration

(info) Learn more on the Non-Blocking Tasks page.

Related Agent Manager / Assistant Changes

Changed Logic in Agent Manager to adapt to non-blocking tasks:

  • If a new task is submitted through the API where parameter "BlockAgent":"false" the following rules apply:

    • While the Agent is busy with such a non-blocking task, a blocking task to this Agent (e.g. service calls, another external "BlockAgent":"true" task) can still be distributed.

    • Vice versa, a blocking tasks prevents further distribution of a non-blocking task to the same Agent.

    • Distribution is only done if there is no other "completely" free agent available.

    • An agent shall not get more tasks than the backend configured amount.

Changes for Agent Assistant:

  • Now able to display multiple call/task toast/extended toast and multiple TCC and ACW for the different toast

    → ACW handling should be the same as for IM: If you allow simultaneous Tasks, no ACW is possible on the service

  • Reporting extended to the additional events where necessary:

    • If working on a non-blocking External Task gets interrupted by a blocking task added, Hold time shall be deducted from the worktime in reporting.

    • The worktime of simultaneous non-blocking external tasks will be counted for each task individually


Use Case

Usage Scenario

Preconditions

  • Service Configuration: "Agents Handle Simultaneous External Tasks" must be enabled

  • "Agent1" Configuration: "Number Of Simultaneous External Tasks" = 2


Scenario 1 - "BlockAgent":"true"Scenario 2 - "BlockAgent":"false"
  1. Agent1 receives a 1st external task where "BlockAgent":"true" and accepts it.
  2. Another external task gets into the queue.

Result: Agent1 doesn't receive 2nd external task because the task currently accepted is blocking it.

  • Agent1 receives a 1st external task where "BlockAgent":"false" and accepts it
  • Another external task  gets into the queue.
  • Agent1 receives a 2nd external task and accepts it.
  • Another external task gets into queue.

Result: Agent1 doesn't receive a 3rd external task as "Number Of Simultaneous External Tasks" = 2

(lightbulb) In both cases a potential free Agent 2 would be preferred if Agent1 is occupied by a task (blocking or not).
Usage Scenarios

Other changes and improvements

Presence Subscription over MS Graph

IMPROVEMENT

Implemented MS Graph presence polling to Configuration of Agent presence. Now supports two options in the Combo box "Presence Type"

  • "MS Graph API Polling"
  • "MS Graph API Subscription (Beta)"
    (warning) Requires a Polling-Interval, named as "Presence Polling Interval (Fallback)" in Configuration to work.

Added subscription for presence changes in AC and use the feature depending on the configuration. Presence changes are handled in the following way:

  • Upon relevant User/Agent changes (e.g. identifiers needed to get the presence, deletion of user, adding of user), delete the subscription in which the user is contained and create a new subscription for the users in that subscription
  • Presence shall not be synced for OffDuty-Agents to lower the polling footprint.
    • When Agents go to OffDuty, send Presence State "None"
    • Once back to a duty-profile, pass last presence state know to AC to AM

Poll request optimization

Microsoft is planning to bill presence-checks in the future. We made the following optimizations due to this:

  • Changes to update presence (e.g. deletion of a user) are collected in a 1-minute-interval, to avoid too many subscription changes.
  • Agents in OffDuty profiles will be excluded from presence polling.


This feature is still in experimental / beta stadium. Performance and usability are still being evaluated by our users. Bugs and changes may occur. Both scope and design may still change significantly.

Conference Warmup Behavior - Configurable expiry period

IMPROVEMENT

For our customers that have to handle huge loads (e.g. for conference creation/warmup) we now offer the possibility to define a time to let "warmup" conferences expire.

3 new ICH synchronized configuration settings (Components)

ParameterTypeDefault
Conference.ExpiryPeriodStartTimeUtcTime in 24h format00:00:00 (not set)
Conference.ExpiryPeriodEndTimeUtcTime in 24h format00:00:00 (not set)
Conference.MinimumLifeTimeInDaysInteger0 (not set)
How it works
  • If set the values are used instead of defaults.
  • When a lifetime for conferences is configured every created conference shall be terminated at some point during configured hours.

Did you miss features from a previous releases? Check out the Release History.