I want to understand how to handle the historical adherence reports when user is moved from one management unit to another management unit.
Example: Dileep is in A management unit from Jun 2024 to Nov2024 and moved to management unit B.
Could someone look into this and let me know how to handle this scenario.
@Dan_Hoffman could you please look into this
I have other query as well like can we also remove a user from management unit and if yes what happens related to Historical Adherence report when we delete user from management unit. Will the removed user data calculated in Reports?
The way users moving management units is handled is a bit unintuitive for historical adherence. The business unit that the management units belongs to also matters. I'll try to express this through different examples myself.
For these examples lets say there is Business Unit 1 which contains Management Unit A and Management Unit B. There is also Business Unit 2 which contains Management Unit C. And lets say just like in your example that Dileep is in Management Unit A at the beginning.
Example 1: Dileep moves from Management Unit A to Management Unit B. In this example all adherence data effectively moves with Dileep to Management Unit B and is removed from Management Unit A. If you make a historical adherence request for Management Unit B it will calculate DIleep's adherence for whatever management unit he was actually in at the time. So, as per your example, if you request Management Unit B for Jun 2024 when he was in Management Unit A, and his schedule in Mangement Unit A has not been deleted, then the request for Management Unit B will return adherence data for Dileep using the schedule from Management Unit A at the time. But if you make a request for Management Unit A you will get nothing at all for Dileep no matter what date range you request.
Example 2: Dileep moves from Management Unit A to Management Unit C. In this case all adherence data for Dileep prior to his move is lost entirely. No matter what you request in either Management Unit you will not get data for Dileep prior to his move. This is because schedule data is stored at the Business Unit level, so when a user moves to a new Business Unit the old schedule data in a different Business Unit is now inaccessible to the new Business Unit and and can not be used for historical adherence.
For your other question. You can remove a user from a management unit, and if you do this, their historical adherence data will no longer show on the report.
HI @Dan_Hoffman
Greetings of the day.
The agent has historical adherence data for Management Unit A.
During a working session today, we tested multiple scenarios.
After moving the agent to Management Unit C, only the adherence data for January 15, 2025, was retained.
Upon moving the agent back to Management Unit A, the full adherence data remained intact.
Ideally, shouldn't the data have been lost in both cases?
Are Management Unit A and C in the same or different Business Units?
Both are in different Business Units.
If the user has a schedule added on January 15th within Management Unit C, then it will use that to calculate adherence. That would explain it showing up for January 15th after the move.
When you move them back to Management Unit A, the adherence is restored and that is expected because all of their old schedules are still in Management Unit A.
Here initially we have Business Unit 1 with Management Unit A and Management Unit B. Today we created both Business Unit 2 and Management Unit C.
This is what we followed for testing the scenarios discussed above. In this case as we created Management Unit C (Business Unit 2) today it is not possible to have Schedules in Jan15 2025 for Management Unit C.
So does the user have adherence data for January 15th when you query Management Unit A or C after you move them to C?
Related to that agent after moving from Management Unit A to Management Unit C.
When we query for Management Unit A it has no adherence data(This is as per design)
When we query for Management Unit C it has adherence data on January 15th.
How long did you wait between moving the user to Management Unit C and making the request? its possible that an internal short term cache was stale and that could maybe cause this. If you wait a couple minutes after moving the user does it still show results on January 15th? This is the only thing I can think of as a possible cause.
I think we waited for about 3 to 5 minutes, not more than that.
if it is cache issue it should display all data but why only one date Jan 15th.
Oh I have one other idea. Are the actuals showing at least some On Queue for the user? When a user goes on queue when not scheduled that can be considered an adherence exception if the "Working Outside Shift Considered Exception" adherence setting is enabled. This can happen even if there is no schedule at all during the requested period and result in some adherence data even if its not super useful without a schedule as well.
Here based on this screenshot i see status as On Queue (Idle) , Actual Category as On Queue and Scheduled Category as Unscheduled.
Note: We didn't change any Adherence settings of newly created ManagementUnit C. All Adherence settings are default values.
The default value for "Working Outside Shift Considered Exception" is enabled. That is why the user has data returned. The user went on queue on the 15th but there is no schedule for Management Unit C for the user so its registers as an exception which also gives them an adherence value. Unfortunately in this case the adherence value doesn't make sense at 1.57% but that is due to the formula for calculating adherence not working too well when there is no schedule for the user.
Thank you @Dan_Hoffman
Based on this I understood
Historical Adherence is calculated based on scheduled vs. actual activity.
Schedules are managed at the Business Unit level.
Adherence settings (tolerance) are defined at the Management Unit level.
Historical Presence and Routing Status (actual activity) are tracked at the User level.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
