Release Notes

25 Aug 2021– LUCS 3.4.04 Bugfix Release

24 Jun 2021– LUCS 3.4.04 Bugfix and Feature Release

27 May 2021– LUCS 3.4.04 Bugfix and Feature Release

30 Mar 2021– LUCS 3.4.04 Bugfix and Feature Release

25 Feb 2021– LUCS 3.4.04 Bugfix Release

21 Jan 2021– LUCS 3.4.04 Bugfix Release

26 Nov 2020– LUCS 3.4.04 Bugfix and Feature Release

11 Nov 2020– LUCS 3.4.04 Bugfix and Feature Release

25 Sep 2020 – LUCS 3.4 Release

We are proud to announce our newest V3.4 LUCS release, featuring many quality-of-life improvements to both configuration and reporting procedures. Some of the highlights include:

• A brand-new Dashboard for you to explore and individualize.
• More convenient ways to handle Web Requests with (automated) Trigger Sets.
• Various BI Reporting Improvements with new Templates and the possibility to embed the BI Report directly in the new Dashboard.
• Service Impersonation functionality for internal transfers.
• New Callback workflow item functionality:
  • Now allowing for customers to keep the position in the queue when requesting a Callback.
  • "Callback" as category in Standalone Opening Hours Calendars.

New Dashboard

A new Dashboard Web Application has been added, including several initial Widgets. This new Dashboard is flexible to use, can be set public to all users and allows to re-assign ownership. 

The Dashboard is still an experimental feature which will gradually replace the existing Frontend. Both applications and services can be installed simultaneously but need different ports for IIS to run in parallel. Advantages of the Dashboard are: 

• Leaner interface, easier to modify and manage
  • Dashboards can be public or personal
  • Dashboards are always assigned to an Organization Unit
• Dashboards have a owner (creator) which can: 
  • Set public (no login required)
  • Change all Properties
  • Can delete
• Optional Support for Power-BI Reporting
   This requires a BI-Pro account and shared URL.  Refer to: Managing BI User and Data access.

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.

How to use

The Dashboard comes with an extra Setup and can be installed alongside the LUCS Frontend if needed.

• Learn more about the Dashboard setup procedure.
• Learn how access and use the Dashboard.

Workflow independent External Web Request and Trigger Sets

External Web Requests could be used in the prev. Version only over a dedicated Workflow Activity and each Webrequest had to be manually configured in each workflow. With the introduction of external web requests and trigger sets, we not only remove this dependency, we extended the events additionally.  

Trigger Sets have been added as additional means to External Web Requests to fill variables and parameters during certain events. The trigger occurrence also depends on related workflow activities, which can (silently) update System / Service context parameters whenever they occur within your workflow.

Once assigned within the Service Workflow Configuration the web requests in a trigger set will be called autonomously and independent from any "External Web Request" workflow steps.

External Web Requests now managed separately

Starting with LUCS 3.4 "External Web Request" Workflow Element properties have moved away from Workflow Instances and into a central "Web Requests" page for central management and assignment to Organization Units.

Good to know:

• Workflow Instances containing Web Requests from LUCS version 3.3 or older will have their web request properties automatically imported into this view.  The naming for these new requests will be "WI_<ImportedWorkflowInstancename>". Any used Service Parameters and other user-defined properties are imported over alongside.
• Existing Web Request data entities appear as Pulldown the "External Web Request" Workflow Elements within your Workflow Instances.
  
• Starting with LUCS 3.4 you can also add Web Requests within External Web Request Trigger Sets

How to use

1. After the 3.4 update, check your (imported or new) External Web Requests entries on the new Configuration page. Existing Workflows will now use of these entries!
2. Learn more about External Web Request Trigger Sets, 
3. Apply the new Trigger Sets within your Service Workflow Configuration. 
    With Triggers Sets enabled, check your existing WF steps as they may now be redundant.

LastAgentTransferType System Parameter

To offer contextual information about the last transfer initiated by an agent a new Service Context Parameter called "LastAgentTransferType" has been added in LUCS V3.4.

 The parameter stores the last type of a transfer triggered by an agent via API or native in the client (SfB/Teams).

By default this parameter is set to "None". It changes changes for every "OnTransfer" trigger for an Agent occurs, to any of the following types: 

• APIBlind
• APIConsultative
• APIAttendant
• NativeAttendant
• NativeConsultative

How to use

1. Create an external Web request that uses the "LastAgentTransferType" parameter in the response content body:

   Example Json Content

   {
   	"lasttransfer": "LastAgentTransferType.Value",
   	"agent": "AgentSipUriWithoutSipPrefix.Value",
   	"caller": "CallerTelNumber.Value"
   }

   XML
2. Within the External Web Request Trigger Sets dialogue, set a Trigger for: Agent - OnTransfer 
3. Receive a service call on any Agent
4. Make a native Transfer call to another Agent → The trigger should be fired with the Parameter LastAgentTransferType

Impersonate Incoming Service on Transfer

It is now possible to configure Incoming Service Impersonation for internal (virtual) transfers initiated by your agents. This allows to see the transfer target to which service the call initially (before the call was transferred in the Workflows) was made to. 

How to use

 Precondition: Requires at least 2 internal services A and B. Afterwards, enable the checkbox in your Service's Call Distribution Policy settings.

 This checkbox must be enabled on the SOURCE service A in order to work in a virtual transfer.  Also see Call Activites → "Silent (Virtual) Transfer"

When enabled on the source (service A), the following scenario applies: 

• Service A takes the call and a blind / virtual transfer to Service B is performed.
• Agent 1 from Service B will see Service B impersonated in both SfB / MS Teams and (if configured) his AA Extended Toast (LUCIE) and take the call, then transfers to Agent 2.
• Agent 2 will see Service A impersonation and take the call.

 Related page to this feature: Call Distribution Policy.

Configure Transfer behavior per Service / Team

Added a new radio button to steer per Service and Team:

• Calls transferred by the agent to external targets will
• Leave the system (Stop Tracking)
• Stay in the system (Continue Tracking) (default)

 Where to find it? Look in the "General Information" Tab of your services

Default System Setting

• A DB Updater system setting stores the default. The DB updater app.config will apply this value for all NEW created services and teams.  Name of the parameter: "Calls transferred by the agent to external targets defaults"
• A new Setting called was added in DB updater to define the behavior for all existing services / teams during an upgrade.
  Default: stay in the system. 

Multiple External System Configurations 

Zendesk and Service Now have been removed from ICH - Interactive Conversation Handler configuration and can be managed as extra pages in the Situational Topology Settings instead. This allows to define individual external system configurations which can be applied 1:1 to your services.

How to use

1. Access the new Configurations via WebConfigurator > Topology > "Zendesk" or "Service Now"
2. Define the configuration
3. Set the configuration within the Service Workflow Configuration under "External Applications"
4. Add either "Create CRM Ticket" (Zendesk) or "Get Caller Information" (Service Now) to your Workflow Structures.
5. Apply the Workflow to your Service

 Related page to this feature: Situational Topology Settings. 

Callback Features

• A new "Callback Category" allows to define Callback Scheduling functionality in conjunction with Standalone Opening Hours.

  

  Opening Hours Categories
• New "Keep Queue Position" for "Create Callback" Call Activity when configuring Callback for your Service. 
  • If this checkbox is enabled the task is added at the same position into the queue that the customer currently had when he decided to requests a callback
  • In case the callback is a "keep queue position" callback, the opening hours for the Callback are ignored.

Business Intelligence and Reporting Improvements

This release brings a lot of improvements on how we handle the LUCS database and Reporting performance. We also updated and reduced the BI report templates that come alongside V3.4.

Historic Reporting Changes

Predictive Forecast

A new Forecast feature in BI allows to predict the next 3 months of Service sessions. 

Will include 2 new BI Files:

• DataExport Report - Necessary to manage / transform data ribbon before export (Python script)
  

  • Will account for holidays and other algorithm-influencing factors such as: 

    • Expected impediments (large backlog, holidays)

    • with possibility to export to CSV
• Look-Only Report - Output in new "ForeCast" Tab
  • No Transform Data necessary → Has predefined filters
  • No export in Look-Only

 This is an exclusive feature to the BI templates.

 Where to find it?  Look in the "04_PowerBI" sub-folder of your source installation file directory. If not provided, ask your Luware Support representative for the latest BI reports for your version.

Excel now exclusively using PowerQuery

By using Power Query we reduced the total amount of Excel report files from 8 to 4. All Agent-Related Reportings are now summarized into a new Agent Power Query Report.

New Excel Files are all now using Power Query for:

• Service
• Agent
• Customer Path
• Survey

 Applicable for V3.3 and higher. 

 Where to find it?  Look in the "03_Excels" sub-folder of your source installation file directory. If not provided, ask your Luware Support representative for the latest BI reports for your version.

Frontend Reporting Changes

New Dashboard using embedded BI Report 

The new Dashboard will display PowerBI.com Reports as directly embedded. This allows for consistency of data display between Frontend and Reporting side without any further delays or data disparity. Furthermore the Report can be directly shared with all Power BI Pro users. 

 Where to find it? 

• The new BI Report access configuration is explained under Managing BI User and Data access.
• LUCS access to theDashboard Dashboard Reporting view is granted via Role Based Access - RBAC.
• After creation of a shared Report URL in BI you can add it to your DFE - Dashboard Frontend installation. The behavior is then identical towards handling the individual Report Files.

Create Empty DB Script 

Our old baseline DB script was based on LUCS 2.9, requiring cumulative updates of all versions that followed. Starting for Versions ≥ 3.3 we've implemented a "Create empty DB" script which assists in a first-time installation of LUCS and TM.

 Where to find it?  Look in the "05_EmptyDB" sub-folders of your source installation file directory.

Index Maintenance Operation 

We continue improving our transformation process in the Reporting DB to avoid avoid future errors and improve performance behavior. Most of tables have one or many indexes to speed up searching of data. During data processing this index is gradually fragmented which may significantly impact query performance over time.

• A database administrator can use SQL Server maintenance plans and other techniques to maintain query performance.
• LUCS database also contains a [mgt].[usp_SysMaintenance_Indexes] stored procedure. It's used to periodically to rebuild or reorganize (faster process) tables’ indexes based on fragmentation level of an index. If the index has one of its levels fragmented more than 30% it will be rebuilt.

 The value can be adjusted by parameters. Note that gathering statistics may require up to 15 minutes on some systems.

 Where to find it?  Look in the Reporting Document that comes with the "07_Manuals" sub-folder of your source installation file directory. 

KPI Changes

• KPI Calculation settings have moved from Frontend Customization and Settings into the the Essential Topology Settings page, making them easier to manage for both the LUCS Web FrontEnd and the new Dashboard.

General Improvements 

• LUCS components now use .NET Framework 4.7.2 to access newest MS Graph API functionality. Please update your .NET Framework to 4.7.2 or newer prior to installation of the new components.
   Head to https://dotnet.microsoft.com/download/dotnet-framework to retrieve the installers. 
   LUCS General Prerequisites have been updated accordingly.
  
  
• LUCS API - New GET/POST user role management functionality. Swagger file documentation updated to V3.4.
  
• Various O365 Login Improvements for various Frontends. Users should now see overall better performance on O365 authentication.
  
• Introduced various new System Parameters to support the new External Web Request Trigger Sets feature:
  • "Agent-"  parameters:
    
    • AgentSid
    • AgentSam
    • AgentUpn
    • AgentDisplayname

 "Agent-" prefix parameters are always filled with the current connected agent. You may use them in External Web Requests. 

• • "Transfer-" parameters: 
    • TransferTargetSipUri
    • TransferTargetSid
    • TransferTargetSam
    • TransferTargetUpn
    • TransferTargetDisplayName
  • ConsultativeIdentifier

Operations Improvements

• Support for Graceful Failover: 
  • Put the agent into the profile he had selected before when AM gets activated
    Possible way: Use the reporting data written to determine the last AgentState and extract the profile information there. DefaultProfile will only be implicitly set, when Agent signs out of S4B/Teams
  • After reconnecting AA to newly activated AM allow to:
    • Save an open NRR request
    • Save an open TCC/CSC request
  • Terminate all ongoing ACW (so that the popup disappears on AA if still present) after AA connect to newly activated AM
  • Reset RONA if necessary, so that a open RONA Popup on AA gets removed
    

Required Lync.Powershell Commands

- Get-CsTrustedApplicationEndpoint
- Set-CsTrustedApplicationEndpoint
- Remove-CsTrustedApplicationEndpoint
- New-CsTrustedApplicationEndpoint
- Grant-CsVoicePolicy
- Get-CsVoicePolicy
- Get-CsVoiceRoute
- Get-CsPool
- Get-CsServerVersion
- Grant-CsConferencingPolicy
- New-CsConferencingPolicy
- Get-CsConferencingPolicy
- Set-CsConferencingPolicy
- Remove-CsConferencingPolicy
- Get-CsExternalAccessPolicy
- Grant-CsExternalAccessPolicy

Known Issues / Limitations

The following features have known issues: 

• Page:
  Database creation

Common Issues

• Logout Session Expiry: The Web Backend does automatically logout after 10 min of user inactivity. However this countdown does not reset while editing properties (e.g. user details, templates, settings) as it should be. This can result in unsaved properties being discarded due to the logout.
  → Workaround: The user has to actively click and change panels / views to reset this countdown. When changing large sets of properties (e.g. templates) recommend to save changes often or increase the Logout expiry duration as explained here.
• Users with "Reporting" Rights in Role Based Access - RBAC will count as "Supervisors" even with just a Reporting Role being assigned.

Microsoft Teams Web-Client

Design Limitation on Microsoft Teams Web Client

The Teams Web Client currently has a known limitation that sends a lot of incorrect status updates especially when refreshing the page in your browser. The effects include: 

• User sporadically appearing as offline.
• Spontaneous switch to an erratic presence status which is apparent in logfiles.
• Multiple status updates within only a few seconds, which increases when user is refreshing the Teams chat window within the browser.

This has a noticeable impact on how Luware products handle Agent presence, availability and reporting features.  → Until this is resolved by Microsoft we strongly advise to exclusively use the locally installed Teams Client App for all productive users of your organization.

Opening Hours

These issues affect Opening Hours

Recurring Events on a DST-Shift-Day	Known Issue (Kendo Scheduler) There is a reported bug in the scheduling component used in Opening Hours Calendar. When you create a recurring event on a DST (Daylight Savings Time) shift day, all related recurring events are shown at shifted time. → A bugfix is outside of Luware scope. Until this is resolved we recommend to create the start of recurring events starting outside of a DST-shift-day.
O365 Calendars: All-day events	Known Issue When using O365 Calendars for opening hours: currently in LUCS 3.3 "all-day" events appear time-shifted via the UTC offset.  BUGFIX Fixed in LUCS-CI component Fix Version: 3.3.20156.9 3.3.20160.1  (for net4.7) LUCS-CI For versions <3.3: We do not recommend to use "all-day" events for O365 calendars until you're ready to perform an Upgrade.