Release Notes
What's new
- Supporting CCE 12.5
- Data integration from ECE 12.0 for the supported data extraction model by eGain and Cisco as part of our CallByCall-Package
- ECE Detail reports about Cases (Report 800), Activities (803) and Events (809)
- ECE Status reports about open Cases (810) and Activities (813, 814)
- ECE Case (840) and Activity performance reports by type (843), queue (844), users and agents (845, 846)
- ECE Handled Activity reports by user (847) and queue (848)
- b+s value lists added to advanced filters for all possible values
- Providing installer for viewer databases with specific time zone
- Other little changes and improvements (see details below)
- Bugfixes
Compatibility
Cisco Contact Center Software
- Cisco Unified Intelligence Center (CUIC) version 11.6 with COP10 or newer, 12.0, 12.5 and 12.6
- Cisco Unified Contact Center Enterprise (UCCE) version 11.0*, 11.5*, 11.6*, 12.0 and 12.5
- Cisco Packaged Contact Center Enterprise (PCCE) version 11.0*, 11.5*, 11.6*, 12.0 and 12.5
* ECE data integration is not supported for versions before CCE 12.0.
3rd Party Software
- Microsoft SQL Server 2012 Standard Edition 64bit
- Microsoft SQL Server 2014 Standard Edition 64bit
- Microsoft SQL Server 2016 Standard Edition 64bit
- Microsoft SQL Server 2017 Standard Edition 64bit
- Microsoft SQL Server 2019 Standard Edition 64bit
Important notes
Layout change for grid reports from CUIC 11.0
Cisco introduced a "Universal Grid" with CUIC 11.0 and changed the format from "auto adjustment" to "fixed width" and removed word wraps. Displayed data will always collapse based on the configured grouping.
Reports designed for CUIC 10.5 and before will not fit to the new grid and need to be adjusted manually or replaced with the new templates of this release.
New Features
This section lists new features or functionality for this version.
BREP-418 - Agent Real Time availability in MRD should be 'No' if routing is controlled by the application
Requirements: If an agent is controlled on a non-voice task by an application what happens after a RONA for instance, the agent availability should be displayed as 'No' instead of 'Yes'. Otherwise no Supervisor can see, that an agent is not available for any new task.
Solution Abstract: The field "AvailableInMRD" has three options:
- 0 = Not Available
- 1 = ICM Available
- 2 = Application Available
This change will be implemented in view "bs_agent_realtime" and will include value 2 to display, that the agent is not available. All other agent real time reports relies on this view and will automatically get the same rule.
Limitation: -
BREP-416 - Add nolock hint to all CallDetail extracts
Requirements: Using the nolock hint for extensive data extractions could prevent from long runtime issues onto Cisco databases.
Solution Abstract: Add nolock hint within data extract queries of all CallByCall procedures to prevent conflicts of frequent data writing within Cisco tables.
Limitation: -
BREP-415 - Runtime of procedure export_ctd optimized
Requirements: In some cases, export_ctd was running for hours due to unknown reasons. We now tried to optimize its runtime and tried to prevent lockings on Cisco database side.
Solution Abstract: Extracting all data with fast filter parameters and doing the joins locally. Adding no lock hint against Cisco views.
Limitation: -
BREP-412 - Add the agent for lost calls
Requirements: We should be able to see the agent, where calls got lost
Solution Abstract: Lost calls are calls that are sent to an agent but did not arrive at the agent's phone. This normally happens, if agents forward the phone number to a un-observed number, if agent targets are not configured properly or if the network fails. In case of identifying a lost call, we should see, to what agent this call was sent. This will allow to investigate such issues more quickly. Therefor, we should add the LostAgentID to the calltype_detail data.
Limitation: -
BREP-385 - Try to optimize procedure "sync_pq_member"
Requirements: This procedure should run within 2-3 minutes also with extensive Precision Routing rules.
Solution Abstract: Today, this procedure extracts the correct mapping of agents based on the PQ and Attribute settings and is part of the Basic load job that runs every 15 minutes. At a customer running version 3.2.3, this SP takes up to 13 minutes to execute. Due to this duration, the execution was moved to the CallByCall Job that runs every 2 hours. We should try to find out the reason of why it takes so long. It's maybe an issue with missing indexes (maybe within temp tables?) that would help to speed it up. If it can't perform better, we have to move it to CbC Job by design!
Limitation: -
BREP-375 - Remove version check in UCCE views for deprecated versions
BREP-374 - Adjust sync_t_Expanded_Call_Variable to also check Persistent and Description fields
Requirements: The "Persistent" flag or the description of an Expanded Call Variable was changed in the Configuration Manager
Solution Abstract: Extend the "update" part in the procedure "sync_t_Expanded_Call_Variable" and check if the fields "Persistent" and "Description" have been changed in the AWDB. Update the corresponding fields in the local database accordingly.
Limitation: -
BREP-373 - Providing installer for time zone viewer databases
Requirements: It should be possible to host multiple bs_Reporting databases onto the same database server for the dedicated time zone setup.
Solution Abstract: If a customer would like to setup several CUIC systems for dedicated time zones, it should be possible to setup all required b+s databases (one for each time zone) onto the same database server. Only one database should load and store all data from the CCE environement while all other databases will just contain database views to point to this main database. The only table for each additional database would be the time zone table, where the target time zone can be configured (used by the b+s time zone procedure within all reports).
Limitation: Administrative reports can only be used from a CUIC system that is connected to the MASTERNODE of the b+s Reporting database (what would not be the case for a node of a dedicated time zone setup). So the configuration of the b+s data mart would require a centralized organisation as it is for CCE as well.
BREP-372 - Supporting MS Azure
Requirements: b+s Reporting Database can be deployed in Microsoft Azure Cloud while CUIC and CCE remains On Prem at customer site.
Solution Abstract: It's possible to install the b+s data mart onto a database server in the MS Azure cloud. The linked server connections to CCE (on premises) are used to build the data mart while CUIC (on premises) fetches data into the reports.
Limitation: Performance testing of a pilot customer has shown that this approach can take up to 4 times longer in the worst case compared to an On Prem database server. Worst case means fetching up to 8000 records within a report for many objects for a short period. On Prem, this scenario takes 15 seconds, in Azure up to 55 seconds.
BREP-371 - Enable Value Lists in advanced filter (Field Filters) within CUIC
Requirements: It should be possible to further refine the results found in Reports. As an example, when using report 143 (based on Report Definition 141) and selecting one call type, 8 teams might have answered those calls. But I only want to see calls that were answered by Team 1 and 2.
Depending on the team IDs and names, it will not be possible to include / exclude certain teams in the field filters, as they might not share any similiarities at all.
Solution Abstract:
Selected Report Definitions will be changed and the corresponding Value List will be added to "ID" fields, where it makes sense.
Limitation: No known limitations.
BREP-369 - Add the RingTime for incoming calls
Requirements: It should be possible to measure how long the call was ringing at the agent's phone before it got answered. This should be available within the call by call detail data, exportetd to BI systems.
Solution Abstract: Include the RingTime in seconds from TCD for all answered calls that are extracted for the CallByCall interface (cth only) as a new field.
Limitation: None
BREP-368 - Add information about who ended an incoming call
Requirements: It should be possible to measure, if the caller (customer) or the called party (agent) disconnected the call. This should be available within the call by call detail data, exported to BI systems.
Solution Abstract: Include this information based on the Call Disposition = 52 "Called Party Disconnected" where it's available with CVP. Extract this information everywhere where it's possible (cth only) and specify this field as 0 = caller disconnected or not detected, 1 = agent disconnected.
Limitation: This feature will only work with CVP as the routing client, hence only for ACD inbound calls.
Bug Fixes
This section lists bug fixes for this version.
BREP-417 - Error in Reports 191 and 192 in multi-peripheral environments
Symptom: When using report 191 or 192, the following error message appears when executing them: "Report execution failed. <...>". This happens when trying to configure the Primary Queue assignment using Precision Queues and if multiple peripherals are in place.
The report will try to insert the same line twice, resulting in a Primary Key violation.
Conditions: Multiple peripherals in place
Workaround: None
Further Problem Description: -
BREP-411 - Importing CUIC Configuration Reports failed for CUIC 12.5
Symptom: When importing the CUIC Configuration Reports, the import will fail for the following report:
cuicscheduledreports (Error message: Unexpected error. This has been logged in the server logs. Please contact Cisco support)
Conditions: Using CUIC 12.5
Workaround: None
Further Problem Description: From Version 11.6 to 12.0 of CUIC, the structure of the table cuic_data:cuicscheduledreports has changed; several fields were removed. As the report definition still had these fields, the import failed in CUIC 12.5. The solution was to newly generate the report definition and export the report again.
BREP-410 - Importing Basic / Basic Admin Reports failed for CUIC 12.5
Symptom: When importing the Basic Reports and the Basic Admin Reports, the import will fail for the following reports:
- 190 (Error message: Invalid footer style. Field name: BucketIntervalName. Valid values: CUSTOMFORMULA)
- 335 (Error message: Invalid footer style. Field name: FirstLoginDateTime. Valid values: CUSTOMFORMULA)
- ConcurrentAgentLicensesUsed (Error message: Invalid footer style. Field name: DateTime. Valid values: CUSTOMFORMULA)
Conditions: Using CUIC 12.5
Workaround: Change the XML files manually and import the affected reports again.
Further Problem Description: For an unknown reason, the affected reports have some strange contents in the XML files, which is not visible in CUIC itself.
For example: report 335 does not have a default custom formula in the footer, but in the XML file the following line can be seen:
<defaultCustomFormula>f18[i]</defaultCustomFormula>**
BREP-381 - Reason Time Percentage calculations may result in division by zero error
Symptom: Reports that use ReasonTime percentage calculations may produce an error. This is due to a division by zero.
Conditions: Any of the reasons mapped to the categories is not equal to zero and the NotReadyTime is equal to zero
Workaround: None
Further Problem Description: To ensure save division, we have added a condition to every fractions calculation. If the divisor is zero, we set the value to zero. In the ReasonTime percentage calculation, we mistakingly check the dividend if it is zero. Thus a division by zero may occur.
BREP-380 - Wrong treatment value in ACD Contact data if TCDs are written later than 2 hours
Symptom: Handled calls within contact summary are counted as other
Conditions: If TCDs are written more than 2 hours later than RCDs are written into database, the call treatment result is built without TCDs and declared as other in this case.
Workaround: None
Further Problem Description: -
BREP-379 - Missing non-voice tasks being handled if Application Task Disposition is null
Symptom: In some rare cases, handled non-voice tasks are not counted as handled.
Conditions: If the ApplicationTaskDisposition field for handled tasks is not set in TCD to default value 0 or 1 as normaly done by b+s connectors (due to unknown reason), tasks are not counted as handled within call by call data extract (also used from Basic Reports). IS NULL condition must be used as another default value for data extract.
Workaround: none
BREP-378 - Load procedure "export_out" fails because the join is using a non-unique field
Symptom: The job "BREP: Dataload for CallByCall-Interface" fails, as the stored procedure "export_out" is failing. The error message indicates, that there is a constraint violation of XAKoutbound_detail, as the procedure tries to insert the same clustered index twice.
Conditions: Cisco Outbound Dialer is being used.
Workaround: None
Further Problem Description: In the stored procedure, we select data for the table t_outbound_detail by querying the Termination_Call_Detail view and joining them with the Dialer_Detail view. For this join, we use the PeripheralCallKey, which is - according to Cisco - unique in Dialer_Detail but not unique in Termination_Call_Detail.
Description for PeripheralCallKey in Dialer_Detail: "An identifier for the call that is provided by Unified CM and is unique to the Unified CM cluster. "
Description for PeripheralCallKey in Termination_Call_Detail "[...] In addition, the identifier used may not be unique depending on the peripheral's implementation.[...]"
Source: Database Schema Handbook
BREP-377 - Missing t_call_type_detail data until further TCDs are written
Symptom: Sometimes calls at the end of a day are missing within the nightly export
Conditions: There is a known delay of 2 hours until call type detail data gets extracted into bs_Reporting database. This delay time was set from the end of the last available TCDs in the system. If no other TCD records are written into the system for some time, the last available records are not loaded anymore until new TCDs are available. The delay time must work in relation to the system time and then load up to the end of available TCDs.
Workaround: none
Further Problem Description: This issue is only important for systems where all data of the previous day needs to be exported at a certain time.
BREP-376 - Table "t_system_settings" is not replicated
Symptom: Changes in table "t_system_settings" are not replicated accross slave nodes.
Conditions: If someone changes the system settings within the corresponding table onto the masternode and does not the same on all other nodes, the result in the reports could be different if CUIC is connected to another data source.
Workaround: Apply the same setting onto all nodes manually
Further Problem Description: -
BREP-370 - Setup may fail if there are multiple reason codes with the same text
Symptom:
When upgrading the Reporting Interface to 3.2, it might happen that the installation fails due to an error:
Msg 2627, Level 14, State 1, Line 57
Violation of UNIQUE KEY constraint 'XAK1Reason_Code_Category'. Cannot insert duplicate key in object 'dbo.t_Reason_Code_Category'. The duplicate key value is (E-Mail).
Conditions:
The error only occurs if there are duplicate reason code texts that are also "mapped" in the table "t_Reason_Code_Mapping".
Workaround:
- Make sure that the job "Synchronize UCCE Configuration" is disabled (as it should be during setup installation)
- Rename the duplicate reason texts in table t_Reason_Code, so that each reason code has a unique reason text. Example: If there are two reason codes with reason text "E-Mail", rename the second one to "E-Mail 2".
- Re-run the installation script (the installer will fill the new table t_Reason_Code_Category with the actual reason code mapping, taken from t_Reason_Code_Mapping)
Further Problem Description: -
Issues fixed in Service Release 4.0.1
BREP-430 - Intraday Reports - Performance improvements
Requirements: Intraday reports take very long to execute in CUIC, if many objects are selected. This is because data is populated for each CallType/Team that the where clause works properly. This should be done in a different way to optimize the performance.
Solution Abstract: Instead of using the query method, we should use an anonymous block where the objects can be filtered in a more specific way. Because we can't update this for existing reports we have to create new reports 121 and 421 and to deprecate reports 120 and 420. The intrady views gets removed as well because they are not used anymore since version 3.0.
Report 421 Team Intraday Staffing will be re-designed to track on chat and email as well.
Limitation: -
BREP-429 - Sorting in report 300 is not consistent
Requirements: In most cases, the sorting in report 300 is correct. However, it may occur that the field LogoutDateTime is not sorted correctly.
Solution Abstract: Add an ORDER BY clause at the end of the query, sorting the output by the agent's last and first name as well as the LogoutDateTime
Limitation: -
BREP-428 - Views "bs_agent_interval" and "bs_outbound_interval" should relate to local tables
Symptom: The views are not working, if there is no connection to the Cisco AW.
Conditions: If someone uses a database snapshot for reporting purposes, those views are not working locally, because they access the global settings from the AW.
Workaround: none
Further Problem Description:
BREP-427 - Missing ECE data if WHEN_MODIFIED is null
Symptom: Some case and activity records are missing in reporting database.
Conditions: Case, activity and link category records are not loaded, if no WHEN_MODIFIED stamp is present in the source database. To have this stamp is essential for loading data, so we have to include the rule of using the WHEN_CREATED in this case already within the ECE infrastructure views.
Workaround: none
Further Problem Description: -
BREP-426 - Missing data in contact summary during normal load
Symptom: There are different numbers of contacts within the contact summary on every node.
Conditions: The normal load process can result into having some ranges, where all the records are missing for around one hour. The same time we noticed, that no records were written at the time when the job should have been executed.
Workaround: Reloading data results into having the same number of records.
Further Problem Description: Because the reason is not fully clear for this issue, we simplified the process of loading data within procedures export_acd and export_mr to have the RCD as the only trigger for loading data. This allows also to remove the requirement of having midnight set for reloading data.
BREP-425 - Duplicate key in export_ctd at time of re-loading data
Symptom: In some specific cases it can happen that there will be a conflict of having a duplicate key after re-loading data.
Conditions: This issue is related to use a wrong date time field after deleting data and reconnecting to the datasource.
Workaround: Use a different time stamp from when the re-load should happen.
Further Problem Description: -
BREP-424 - Load procedure export_all fails with duplicate keys
Symptom: Load pocedure export_all fails due to duplicate key within database bs_Reporting
Conditions: Because of unknown reasons, Cisco HDS writes agent logout records and deletes some of them afterwards. After a certain time, the same reccords are logged in HDS again with new RecoveryKey and new DbDateTime. This results into a primary key conflict within our database, because we do not delete the previous records and we have our own primary key.
Workaround: The conflict can be resolved by re-loading data but will apear again as soon as the same happens again in HDS.
Further Problem Description:
BREP-423 - Interface setup may fail due to collation conflict within trigger "check_time_zone"
Symptom: The Reporting Interface setup may fail with the error: "Cannot resolve the collaction conflict between "Latin1_General_BIN" and "<any other Latin1 collation>" in the equal to operation.
Conditions: SQL Server is not using "Latin_General_BIN" as collation.
Workaround: Manually adapt the installation script.
Further Problem Description: -
BREP-422 - CallByCall loadjob fails with SQL error 537
Symptom: CallByCall loadjob fails with SQL error 537: Invalid length parameter passed to the LEFT or SUBSTRING function.
Conditions: Unknown (Variable10, which is the field being checked, is not being set anywhere in the script. Most of the times, this field is set the NULL, but sometimes contains an empty string, possibly being the cause of the issue)
Workaround: None
Further Problem Description: Affects load procedures export_acd and export_mr
Issues fixed in Service Release 4.0.2
BREP-439 - Replacing RouterCallKeySequenceNumber with timestamps to join RCD and TCD
Requirements: RouterCallKeySequenceNumber is a fragile parameter within RCD and TCD and often not correct (duplicates) due to unknown reason. This parameter is used to join RCD and TCD data within load procedure export_ctd and should be replaced with timestamps of RCD and TCD.
Solution Abstract: Instead of joining the range of TCD records between sequence numbers of the RCD records the join can be done by using the BeganRoutingDateTime of RCD and the starting timestamp of the TCD records. This has to be implemented into export_ctd only (export_acd and export_mr handle this join differently).
Limitation: -
Issues fixed in Service Release 4.0.3
BREP-454 - Replication job fails if updating time zone values
Symptom: If time zone values has changed on the masternode, the replication job fails.
Conditions: The trigger that prevents from entering invalid time zone values affects the replication procedure. This trigger should only be available on the masternode, where the configuration is set.
Workaround: Configure the same values for the time zone on every slave node manually. As soon as the values are the same, the job will not longer fail.
Further Problem Description: -
BREP-453 - Time zone configuration resets to UTC / UTC with any installation script or service release
Symptom: After installing a service release, the configured time zone is reset to source = UTC and target = UTC
Conditions: Configure any time zone conversion within table "t_time_zone". Then upgrade to version 4.0.0 or install SR 4.0.2. After this upgrade, the time zone configuration is set to the default values UTC.
Workaround: Re-Configure the time zone after the upgrade manually.
Further Problem Description: -
BREP-452 - Time zone alignment for ECE data to source time zone is missing
Symptom: ECE data is present in UTC time zone within b+s reports.
Conditions: ECE reports displays time stamps in UTC while CCE data is displayed in any time zone other than UTC.
Workaround: None
Further Problem Description: ECE data has to be converted to the source time zone as configured for the CCE system within the ECE views. This aligns ECE data to the same time zone as CCE stores its data. The time zone function finally converts both data to the target time zone. The issue here is that the conversion is missing within the ECE views.
BREP-451 - Procedure sync_t_EGICM_USER is not part of the job BREP: Synchronize ECE Configuration
Symptom: No CCE Agents are available in view bs_ece_activity_detail
Conditions: No data are loaded into table t_EGICM_USER because the sync procedure is not included in the sync job.
Workaround: Enter the following statement in the job "BREP: Synchronize ECE Configuration" manually: exec dbo.sync_t_EGICM_USER
Further Problem Description: -
BREP-449 - Call Type Detail completed result missing for one specific call scenario
Symptom: Some calls have CompletedResult = NULL within Call Type Detail data.
Conditions: Calls that are sent from queue to agent and abandoned before ringing at the agent (CallDisposition = 4: Abandoned delay due to switch processing) are not classified as abandoned. This is due to a missing rule to identify abandoned calls at agent.
Workaround: None
Further Problem Description: The same rule is present in contact detail data as well and has to be fixed the same way in procedure export_acd.
BREP-448 - bs_skillgroup_interval performance update
Requirements: The performance of Skill Group Performance Reports should be much better with SQL Server 2014 and having Reports Version 3.0 or higher in place.
Solution Abstract: In Version 3.0 we introduced the time zone conversion function within all reports. This function seems to have performance issues on older SQL Server versions before 2016. To solve this issue, we changed the view bs_skillgroup_interval to actually change the execution plan on SQL Server 2014, what makes it much faster now.
Limitation: None
BREP-447 - Reduce refresh rate to 15 seconds for reports 390, 490 and 590
Requirements: Membership reports should also be available as real time reports.
Solution Abstract: Today, membership reports are categorized as configuration check reports with a refresh rate of 3600 seconds. Because they are also useful to display the current agent state in real time, they should refresh automatically as often as possible. If they are used to verify the configuration, they can be paused within CUIC.
Limitation: None
BREP-446 - Transferred non-voice-tasks in bs_calltype_handled_detail are missing
Symptom: Transferred Emails are not counted as "Transferred" in view "bs_calltype_handled_detail".
Conditions: If an Email is transferred to another queue, it's correctly counted as "Transferred" everywhere else but not within the calltype handeld detail data and reference reports. This is due to a missing rule for non-voice-tasks within the data load procedure "export_cth". To get this corrected, data must be re-loaded with the fixed version of this procedure.
Workaround: None
Further Problem Description: -
Issues fixed in Service Release 4.0.4
BREP-455 - Time zone alignment for ECE data has to be done within data load
Requirements: The time zone conversion of ECE data into the source time zone of CCE does not work within the view in a sufficient way, because the indexes of the date time fields are not taken into consideration this way. Any query against these views while using a specific date range (what always is the case) will do a table scan and therefore run for minutes.
Solution Abstract: To align ECE data with CCE data and having the best performance as possible, we have to convert ECE data into the same time zone as CCE. Only this way we don't need to require CCE data to be stored in UTC, what would be an issue at most of the installations.
Limitation: If the time zone configuration is not set properly before loading ECE data, ECE data has to be re-loaded again.
Issues fixed in Service Release 4.0.5
BREP-478 - Missing data in bs_calltype_detail in cases with limits and same DbDateTime
Symptom: Some records from RCD are not loaded into t_calltype_detail table.
Conditions: If some records have the same DbDateTime stamp into Cisco Database and some records are not loaded due to any limit, they are also not loaded at the next job runtime.
Workaround: None
Further Problem Description: The load procedure must be re-designed to load everything or nothing with the same DbDateTime stamp. The same rule has also to be included into calltype_detail_handeld and dn_calls to prevent the same issue there.
BREP-477 - Wrong CompletedResult Abandoned / ShortCall in CallType Detail data
Symptom: In some cases, a short call is classified as "Abandoned" or vice versa, thus the WaitTime contradicts the CompletedResults
Conditions: One known example is when the caller abandons the call after a RONA at the first agent
Workaround: This issue was already fixed in the view "bs_calltype_detail" with BREP-245.
Further Problem Description: Although the WaitTime is calculated correctly, the CompletedResult sometimes does not match the actual result.
BREP-474 - Review performance of bs_skillgroup_interval again
Requirements: Review the changes done in issue BREP-448 in regards to precision queue routing in multi-peripheral deployments.
Solution Abstract: Although the performance was improved for older versions of SQL server, we did not take into consideration multi-peripheral environments when distributing calls using precision routing. The goal is to improve the performance while also displaying the correct numbers, what is not possible for multi-peripheral deployments. So we have to reverse the change and offer the performance update as a workaround for single-peripheral deployments only.
Limitation: Workaround not possible for multi-peripheral deployments. Here the only option would be to upgrade to a newer version of SQL server.
BREP-471 - Clarify separation of ActiveTime for voice (Agent Performance) in documentation
Symptom: For Calls that are routed by the QueueToAgent Node the corresponding Time in AgentPerformance is logged as DNActiveTime not as ACDActiveTime.
Conditions: The ActiveTime for voice is separated by the default SkillGroup into ACD and DN categories because there is no separation available into the data model. ACDActiveTime represents the active status for ACD Queues and DNActiveTime the status for the default Queue. In case of a QueueToAgent call, the call is logged for the default Queue and therefor as DNActiveTime. This exception needs to be addressed into the field description of the interface (bs_agent_interval) and all related reports (330, 340, 430, 433, 440, 443).
Workaround: There is no option to change the status time for QueueToAgent calls into the ACD category. As a workaround, use the field ActiveTime, what includes the active status for the whole voice channel without any separation.
Further Problem Description: The same clarification will be applied to the fields ACDTransferred and DNTransferred, where the default SkillGroup is the only categorisation option too.
BREP-470 - RONAs on QueueToAgent should be included in ACDRONA as well
Symptom: RONAs that happen on the default SkillGroup (e.g. by using a Queue2Agent node) are not considered as ACD RONA within Agent / Team performance reports
Conditions: Call is sent to agent using a Queue2Agent node and the agent does not answer the call, thus producing a RONA
Workaround: -
Further Problem Description: This data is missing, because data from the default SkillGroup is excluded for this field. The same applies to the fields ACDAbanRing and ACDRingTime what will be corrected with this fix as well.
BREP-469 - Performance improvement for contact data load
Requirements: MR data should handle long running contacts faster and with less unneeded data. Further the insert process of history data (TCD) should be done without updating process and just insert data based on DbDateTime for ACD and MR data.
Solution Abstract: Several adjustments and changes based on investigation sessions at customer system. This also includes specific execution plan of SQL Server if hosted in Azure Cloud.
Limitation: -