When I look in Genesys CLoud Platform for the date period of 1 month, I get an adherence value for a user that only worked from the 22nd-31st of the month. The data filter in the platform is set from the 1st of the month to the 31st and the aggregate is the same when I change the start date to the 22nd.
However, when I apply the same to the API start and ends dates, I get null for the userId for the month with start date 1st and end date 31st.
Does anyone know how I would go about handling these null values for specific users who are not always present at work on the start and end dates that are inputs for the API request? This seems to be causing the null values.
PS: I'm using the following functions in my code:
1.... .WfmHistoricalAdherenceQueryForTeams()
2.....post_workforcemanagement_team_adherence_historical(team_id, body=body)
3.....get_workforcemanagement_adherence_historical_job(api_response.id).download_urls
and then requests package,
To make things clear, the user does not need to be present on the first day of the requested date range for them to appear in the adherence results. So if you make an API request from the 1st to 31st and the the user only worked starting on the 22nd, they would appear in the results. So I have a few ideas for you to check first to make sure the SDK is being used in the way you intended.
When getting the adherence values in the platform, are you querying by Management Unit or Team? From the function calls you posted, you are using the Teams API not the Management Unit API. So I just wanted to make sure that was not a mistake.
If the Teams API is what you desire, I would first verify that the Teams ID is correct and matches the ID of Team you queried in the platform. If the Teams ID is correct, then next I would verify that the user is still a member of that Team. If the user was moved out of the team, they would no longer show up in the adherence results.
Hi Dan :),
Thanks for getting back to me. I just checked and am using a particular team_id in the post_workforcemanagement_team_adherence_historical() function. I can see the employee of interest was a member of the team for the entirety of the month (April) (1-31st). The team_id is consistent and the employees are not switching teams where they are missing months. I'm running monthly aggregations for Jan 2024- June 2024 and several employees are missing several months. E.g. Employee A might have a null value returned for February, Employee B might have a null value returned from April.
Thanks again so much for investigating this with me, happy to provide any further information.
Does that mean that employees, while not switching teams during their null value months, are switching teams at other times? One thing about the historical adherence API, is that it does track their team membership historically. That is, it will always only show adherence values for users that are currently members of the requested team. And I am wondering if this is possibly the source of your issue.
To illustrate this here is an example: If Employee A is in Team 1 for all of April and switches to Team 2 for all of May, you would not see Employee A in the adherence results for a request of all of April for Team 1. You would have to query all of April for Team 2 to get Employee A's adherence values for April.
One other possibility is to check if the users moved to different Business Units at all during this time. When users move Business Units their historical adherence data is effectively lost.That generally would show as no historical data showing up for any days before they moved to the new Business Unit, which I'm not so sure you are describing since it sounds like the null values are sporadic.
Thanks for getting back to me again. The employees of interest are currently in the same team and business unit. The other clue that makes me think it's to do with the dates side of things is if I make body.start_date parameter for the query on a public holiday (e.g. Monday April 1 2024) was Easter Monday, (.end_date being 30 April), then I receive null for all the employees. However, if I make the start_date April 2, I at least get actual historical figures for a majority of the employees with the exception of those who didn't work that day.
Furthermore, I just ran a test on January starting date set to January 2nd. I get the monthly aggregate for all employees who worked on January 2 and whom also have a daily aggregation figure for the 2nd as well. But all those employees who returned to work later in the month (e.g first day at work in January 3rd, Jan 22nd etc), I receive a null value for those employees only. If I set to January 1st as start_date, I get null for all because it was a public holiday. Please let me know your thoughts on this
So I have been trying to reproduce this issue myself but so far have not seen it. Everything has been working as expected when I try. I have one more question just to make sure I fully understand your issue. When you say you get a null for a user, does that mean the user is not showing up at all in the results? Or are you saying that you are getting the user and their daily metrics, but just their overall adherence and/or conformance values for the user, what I believe you call the monthly aggregate, are missing?
Thanks for your continued efforts and support looking into this. To be clear, the null values means users are not returned at all for the time period of interest in these cases. E.g., for January, we are only receiving data for 7 of the 15 employees of interest. No user_id nor daily metrics for the missing ones.
Just to confirm, I'm using the Python SDK. Are you reproducing the issue with this?
I am not using the Python SDK, I was testing with the backing API using HTTP requests directly. You are right that this is possibly an issue with the SDK itself and not the API. Especially if the issue doesn't appear in the Platform like you said. The SDK is not something I am too familiar with so I cannot provide good help with that. So at this point I would suggest that you open a Customer Care ticket to get more in depth support.