Legacy Dev Forum Posts

 View Only

Sign Up

User aggregate query qualifier ON_QUEUE definition

  • 1.  User aggregate query qualifier ON_QUEUE definition

    Posted 06-05-2025 19:20

    Renaud_Larcier | 2019-12-23 10:22:16 UTC | #1

    Hello

    We're using following query : https://developer.mypurecloud.com/api/rest/v2/analytics/user_aggregate.html

    we looking at following qualifiers :

    1. tOrganizationPresence contains following qualifiers:
      1. AVAILABLE
      2. BUSY
      3. BREAK
      4. ON_QUEUE
      5. OFFLINE
    2. tAgentRoutingStatus contains following qualifiers:
      1. INTERACTING
      2. NOT_RESPONDING
      3. IDLE

    We have following assumption ONQUEUE = (INTERACTING + NOTRESPONDING + IDLE ) but the numbers don't seem to add exactly up

    Are we using the wrong assumption - are there other qualifiers we should consider in our formula? Is it because there is maybe tagentroutingstatus values in previous or next interval ?

    Tx Renaud


    crespino | 2019-12-23 17:08:05 UTC | #2

    User Aggregate generates pre-calculated results, so what you are checking the values against when you state "the numbers don't seem to add exactly up"? Are you comparing against values from the User Status Detail Report?


    Renaud_Larcier | 2019-12-31 12:40:53 UTC | #3

    tx for response we take values for INTERACTING/NOTRESPONDING/IDLE AND ON QUEUE in the same result txt file Yet the ONQUEUE is not exactly equal to the sum of the 3 other qualifiers

    On queue value is 23678248 while sum of the 3 other qualifiers is 23690421

    Below the result table from a single user aggregate query

    Column1.interval

    Column1.metrics.metric

    Column1.metrics.qualifier

    Column1.metrics.stats.sum

    Column1

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tAgentRoutingStatus

    INTERACTING

    20624787

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tAgentRoutingStatus

    NOT_RESPONDING

    17418

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tAgentRoutingStatus

    IDLE

    3048216

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tOrganizationPresence

    ON_QUEUE

    23678248

    23690421

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tOrganizationPresence

    03af8d19-653f-45f7-97db-803bf86bde50

    3310054

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tOrganizationPresence

    227b37e2-f1d0-4dd0-8f50-badd7cf6d158

    4296171

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tOrganizationPresence

    6a3af858-942f-489d-9700-5f9bcdcdae9b

    610552

    2019-12-14T00:00:00.000Z/2019-12-14T23:59:59.000Z

    tOrganizationPresence

    ccf3c10a-aa2c-4845-8e8d-f59fa48c58e5

    54503975


    crespino | 2019-12-31 15:39:03 UTC | #4

    I can see why you would think that ONQUEUE = (INTERACTING + NOTRESPONDING + IDLE ), but that is actually an incorrect assumption. ON_QUEUE is a presence status and the others are routing statuses and they are tracked separately, so the times will be close but will never add up exactly the same.

    For instance I subscribed to the "v2.users.{id}.activity" event and I received this where "IDLE" is my routing status and "ON_QUEUE" is my presence:

    { "id": "1c1ca8b5-8740-481e-92f5-cf23870284bd", "routingStatus": { "status": "IDLE", "startTime": "2019-12-31T15:28:09.980Z" }, "presence": { "presenceDefinition": { "id": "e08eaf1b-ee47-4fa9-a231-1200e284798f", "systemPresence": "ON_QUEUE" }, "presenceMessage": "PureCloud World Domination", "modifiedDate": "2019-12-31T15:01:33.319Z" }, "outOfOffice": {}, "activeQueueIds": [ "162d472f-adc3-4cdd-8222-98379ee38390" ], "dateActiveQueuesChanged": "2019-08-15T19:32:50.765Z" }

    As a side note... You are using tOrganizationPresence and you may want to use tSystemPresence to factor in any custom statuses.


    Renaud_Larcier | 2020-01-02 11:54:44 UTC | #5

    tx - that makes sense


    system | 2020-02-02 11:54:47 UTC | #6

    This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.


    This post was migrated from the old Developer Forum.

    ref: 6795