Genesys Cloud - Developer Community!

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

We are trying to achieve a result similar to Tatjana's. We're trying to send an email notification when an agent has submitted a Time-off Request. Some of our upper leadership and team managers aren't always in Genesys Cloud, and so having an email notification is a feature they had before we used Genesys WFM and would like to have back. If this wasn't intended to be used in WorkFlows, why would it be a topic in Triggers that call a WorkFlow?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

We are trying to achieve a result similar to Tatjana's. We're trying to send an email notification when an agent has submitted a Time-off Request. Some of our upper leadership and team managers aren't always in Genesys Cloud, and so having an email notification is a feature they had before we used Genesys WFM and would like to have back. If this wasn't intended to be used in WorkFlows, why would it be a topic in Triggers that call a WorkFlow?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

I don't have a great answer to your question but it sounds like this topic might be a better fit for your needs?

v2.users.{id}.workforcemanagement.timeoffrequests

We are trying to achieve a result similar to Tatjana's. We're trying to send an email notification when an agent has submitted a Time-off Request. Some of our upper leadership and team managers aren't always in Genesys Cloud, and so having an email notification is a feature they had before we used Genesys WFM and would like to have back. If this wasn't intended to be used in WorkFlows, why would it be a topic in Triggers that call a WorkFlow?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

I had originally tried that one, but my findings of that topic are for only when the request is updated (either denied or approved). The initial submission of the timeoff request doesn't initiate a trigger. I may be looking at it wrong though.

I don't have a great answer to your question but it sounds like this topic might be a better fit for your needs?

v2.users.{id}.workforcemanagement.timeoffrequests

We are trying to achieve a result similar to Tatjana's. We're trying to send an email notification when an agent has submitted a Time-off Request. Some of our upper leadership and team managers aren't always in Genesys Cloud, and so having an email notification is a feature they had before we used Genesys WFM and would like to have back. If this wasn't intended to be used in WorkFlows, why would it be a topic in Triggers that call a WorkFlow?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?

I had originally tried that one, but my findings of that topic are for only when the request is updated (either denied or approved). The initial submission of the timeoff request doesn't initiate a trigger. I may be looking at it wrong though.

I don't have a great answer to your question but it sounds like this topic might be a better fit for your needs?

v2.users.{id}.workforcemanagement.timeoffrequests

We are trying to achieve a result similar to Tatjana's. We're trying to send an email notification when an agent has submitted a Time-off Request. Some of our upper leadership and team managers aren't always in Genesys Cloud, and so having an email notification is a feature they had before we used Genesys WFM and would like to have back. If this wasn't intended to be used in WorkFlows, why would it be a topic in Triggers that call a WorkFlow?

If you let me know what you're trying to solve I can try to help. Otherwise, we do have an ideas portal where you can enter your use case and what you need to accomplish it.

 
Genesys Cloud Ideas Portal

Hi Brian,

I just wanted to let you know that I would park this for now, since the topic is not intended for workflow. The use case we were trying to solve was too premature for what we currently have available.  We'll continue to monitor new topics for the workforcemanagement for the Process Automation. 

Thank you for getting back to me so quickly. 

Yes. Mutable group ID is different, and additional notifications where added under otherNotificationIdsInGroup, which is expected when new notifications are added for that user (until the "group" is full), as per my initial response.

This topic was not intended to be used for workflows. Can you explain further what you're trying to accomplish?

Did you see the question related to the difference in the events, JSON files provided in my original post? 

That is intentional. The notification topic was never intended to be invoked from a workflow, as it is solely intended to be used to populate the "inbox" of the logged in user. The topic itself goes hand-in-hand with the api routes I mentioned, they're the two halves of the same feature.

Perhaps if you can tell me more about what you're trying to accomplish I could point you at some better topics/apis to accomplish your goals?

Hi @Brian Trezise,

I've tried that API previously, and it is very limited . First, it requires user context i.e. it cannot be invoked from a Workflow, and it also returns the same mutableGroupId for the logged-in user (via implicit grant). Here is the excerpt from the API response on mutableGroupId attribute, and you can see that there are multiple instances of it: 

There is an API route to get notifications for the current logged in user (getting notifications for any user other than the currently logged in user is not possible via the api):

GET /api/v2/workforcemanagement/notifications

This route here is related, for marking a notification read or unread

POST /api/v2/workforcemanagement/notifications/update

@Brian Trezise, 

Thank you!

The description for the topic v2.users.{id}.workforcemanagement.notifications  is "Notification that a user's wfm inbox has a new message" 

We understood this as you explained, and we noticed the difference in mutableGroupId for the events emitted when the user submits time-off notifications in Process Automation. At the same time, the same topic had only one event in Developer notifications (Web Socket). 

Are there any APIs from which we can get the details about the WFM notification groups? 

Without getting too far into the weeds, wfm notifications are stored in "groups", with a mutable group id. Any time anything changes for any notification within that "group", the mutable group ID is changed for all of the notifications in the group. It can be viewed as a kind of a version for those notifications, and the latest mutableGroupId is needed for PATCH calls to mark individual notifications as read/unread. This is why changing or adding a notification results in updates to multiple other notifications.

Here is the challenge we are facing and need your help: 

We created a trigger for the following event: v2.users.{id}.workforcemanagement.notifications, data format: json. The workflow that is triggered by this event has some custom logic on how to handle Time Off requests. 

The problem we're encountering is that as soon as the workflow is triggered, the workflow is triggered more than once, and the event body has always the same "id" and "timestamp" and different "mutableGroupId". We have performed a few tests for the topic v2.users.{id}.workforcemanagement.notifications:

• Subscribing to the event via the Developer Notification tool (Web Socket) 
• Trigger Workflow via Process Automation

Can you please advise on what is mutableGroupId used in WFM events? Why there is a difference for the same event between Developer's Notification and Process Automation ?