Genesys Cloud - Developer Community!

 View Only

Sign Up

Back to discussions
Expand all | Collapse all

Detecting When a Workitem Is No Longer Assigned via v2.taskmanagement.workitems.users.{userId}

  • 1.  Detecting When a Workitem Is No Longer Assigned via v2.taskmanagement.workitems.users.{userId}

    Posted 25 days ago

    Hi all,

    We're building a frontend app that integrates with Genesys Cloud workitems and are running into an issue keeping frontend state in sync when a workitem is unassigned from a user but not terminated.

    Setup

    • On app load, we use the workitems query endpoint to fetch all non‑terminated workitems for the logged‑in user and render them in a list.
    • To keep this list up to date, we subscribe to: v2.taskmanagement.workitems.users.{id}
    • WebSocket events are used to update frontend state:
      • Add newly assigned workitems
      • Update existing ones
      • Remove workitems when:
        • they transition to terminated, or
        • the assigneeId no longer matches the logged‑in user

    This works well for new assignments, updates, and terminated workitems.

    Issue

    When a workitem is unassigned without being terminated (e.g. another agent takes ownership or it's moved to a different queue):

    • The last event we receive on the user topic sets assignmentState to "Disconnected".
    • The subsequent update where assigneeId is removed or changed is not received on this topic.
    • As a result, the workitem remains in our frontend state even though it's no longer assigned to the user.

    Why This Is a Problem

    Subscribing to per‑workitem topics like: v2.taskmanagement.workitems.{id} doesn't feel viable due to:

    • WebSocket topic limits
    • Constantly reconciling which workitems are still assigned

    From a consumer perspective, it feels like the user‑scoped topic should emit a final event when the assignment changes, since that's when the workitem stops being relevant to that user.

    Current Workaround

    After receiving an event with assignmentState === "Disconnected", we do an extra fetch of the full workitem and remove it from state if the assigneeId no longer matches. This works, but feels more like a workaround than an intended pattern.

    Questions

    • What is the recommended way to determine that a workitem should be removed from user state when it's no longer assigned?
    • Is "Disconnected" the only reliable signal, and should it always be followed by a fetch?
    • Is it expected that an assigneeId change does not result in a final event on
      v2.taskmanagement.workitems.users.{id}?

    Any guidance on the intended design or best practice would be appreciated.

    Thanks!


    #PlatformAPI
    #PlatformSDK

    -------------------------------------------


Related Content