WFM Notifications not showing in custom React desktop

Genesys Cloud WFM
1

Hi all,

We’re building a custom agent desktop with React and the embeddable framework - v3.8.2. We want to show the WFM notifications directly in the UI so agents don’t have to open the main Genesys menu. It’s… not working as expected.

The notification list doesn’t update when a new schedule change happens. We’re calling the GET /api/v2/workforcemanagement/notifications endpoint, but the response is empty even when the agent has alerts in the standard interface.

The client app SDK - v1.45.0 is initialized, but maybe the permission is wrong? We’ve tried to use the notification channel to listen for events, but the WFM stuff doesn’t seem to trigger the same way as a call or a chat.

Here’s the response we get from the API:

{
 "entities": [],
 "pageSize": 25,
 "pageNumber": 1,
 "total": 0
}

The agent has the correct role for WFM, but the custom desktop is doing jack all. We tried to mark them as read using POST /api/v2/workforcemanagement/notifications/update to see if it forces a refresh, but it doesn’t change the list.

1 Like
2

The API documentation for GET /api/v2/workforcemanagement/notifications indicates this is a polling endpoint rather than a push mechanism. Is the application relying solely on this call, or is there a subscription to the notification service as described in similar community threads regarding real-time updates?

GET /api/v2/notifications/channels/{channelId}/subscriptions
3

I added the subscription to the notification service. Now the list updates immediately when the change happens.

1 Like
4

Cause: genesys-cloud-sdk won’t clear the notification count automatically. The UI keeps showing old alerts if you don’t explicitly mark them as read.

Solution: Use POST /api/v2/workforcemanagement/notifications/update to clear the list.

{
 "notifications": [
 {
 "id": "notification-id-here",
 "read": true
 }
 ]
}
5

The fix in the earlier reply is spot on. If you don’t clear those, agents just ignore the notifications entirely, which kills any attempt at keeping them on schedule.

Are you also tracking if they’re actually reading these? We found a workaround where we log the update call to a custom KPI just to see who’s actually paying attention.