Query related to calculations of adherencePercentage and conformancePercentage for WFM Historical Adherence

[Dileepkaranki]

Query related to calculations of adherencePercentage and conformancePercentage for WFM Historical Adherence.
Endpoint used is Request to fetch the status of the historical adherence bulk job. Only the user who started the operation can query the status. Job details are only retained if the initial request returned a 202 ACCEPTED response
Could some one look into this and let me know the formulas

[Dileepkaranki]

Hi @brian.trezise
Regarding
Old Genesys Forum Thread
you mentioned only how to calculate start date of the day could you also guide us regarding end date of the day calculation, Adherencepercentage and conformancePercentage calculations.

[brian.trezise]

A day is defined as starting at 00:00:00 and ending at 00:00:00 of the next day in the time zone provided in your request. Note that this may or may not be exactly 24 hours - if the time zone has daylight savings rules then on the actual day of the DST transitions it will have correspondingly more or less hours, and you'll have to account for that in your own logic.

I'm not sure what you're asking regarding adherence percentage or conformance percentage.

[Dileepkaranki]

In the web API response data, which fields/properties are being used to calculate:

1. The adherence percentage
2. The conformance percentage?"

This would help identify the specific data fields from the API response that are being used in these calculations.

In an Old genesys forum discussion, it was explained that the start date of the day is calculated by adding dayStartOffsetSeconds to startDate from the dayMetrics data. Following this same logic, how would we calculate or determine the end date of the day?

[Dan_Hoffman]

The formula used to calculate adherence and conformance percentages can be found here:

How Genesys Cloud calculates adherence and conformance - Genesys Cloud...

[Dileepkaranki]

If we aim to support multiple time zones and there isn't a granularity property like PT30M available in the request body, we need to consider how to structure our queries. For instance, if we want to retrieve adherence data for the past day in UTC, should we break the request interval into 30-minute segments?

[Dan_Hoffman]

So all data is returned in UTC regardless of the time zone parameter. The time zone parameter only changes what is considered the start of the day for the day metrics but it will still be returned in UTC.

Here is how I would recommend using the bulk historical adherence endpoint. You should make sure in the request that all the management units you request have the same time zone configured, and set that as the time zone parameter. Also make sure that the startDate and endDate you provide are set to the start of day for that time zone. For example if I wanted to request yesterday's adherence for two management units in the same business unit, and that business unit was configured for the America/New_York time zone, the request body would look like this:

{
    "timezone": "America/New_York",
    "items": [
        {
            "managementUnitId": "someId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        },
        {
            "managementUnitId": "someOtherId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        }
    ]
}

This will return adherence for November 11th for those management units. Since the start of day for the America/New_York timezone for that day is 2024-11-11T05:00:00Z, there will only be a single day metric that is lined up perfectly with the requested date range.

[Dileepkaranki]

Thank you @Dan_Hoffman
Currently we are going with your suggestions by using customer specific Timezone instead of UTC. Will revisit this again to support multiple timezones by saving data with Granularity PT30M and UTC Timezone.

[Dan_Hoffman]

I don't know exactly what you are trying to accomplish, but I do have a bit of a warning about the 30 minute granularity approach. Making multiple historical adherence requests, each with a range of only 30 minutes, could quickly run into rate limiting, if the total range of data you require is large. It technically could work but could be very slow to make all the requests.

[Dileepkaranki]

@Dan_Hoffman I understand your warning regarding Querying with a granularity of PT30M may lead to slow data loading and rate limiting issues. We retrieve bulk data only for initial data loads and on regular basis we pull only past 1week data.
My goal is to store these PT30M segments in UTC and generate adherence reports that can be displayed in multiple time zones by allowing users to select their preferred time zone via checkboxes in Power BI.