Workforce Engagement Management

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.

There are probably many enhancements and ideas around this. I did a quick search in Ideas Lab, but did not find anything great. There are a couple that mention full on 'locking' of an agent's entire schedule when someone is editing them. I am not a fan of locks like that (e.g., Suzy Supervisor locks Bob's schedule while making edits, gets sick and leaves without unlocking) for several user experience reasons.

I know others have asked for more information on the conflict (e.g., inform the user who made the modification that got in first and when it was made).

Then there is also potentially reconsidering at what level the conflict granularity is with maybe some rules (e.g., allow a conflicting change to an agent's schedule if weekly paid time is not violated).

And the grand idea of course would be Google Docs style completely concurrent editing. That of course comes with other challenges besides the engineering effort (e.g., two people editing the same day and agent and some overlapping activities - "hey, my changes just disappeared").

Tagging @Paul Wood​ on the Product Management side. I know we always like feedback on possible enhancements.

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.

There are probably many enhancements and ideas around this. I did a quick search in Ideas Lab, but did not find anything great. There are a couple that mention full on 'locking' of an agent's entire schedule when someone is editing them. I am not a fan of locks like that (e.g., Suzy Supervisor locks Bob's schedule while making edits, gets sick and leaves without unlocking) for several user experience reasons.

I know others have asked for more information on the conflict (e.g., inform the user who made the modification that got in first and when it was made).

Then there is also potentially reconsidering at what level the conflict granularity is with maybe some rules (e.g., allow a conflicting change to an agent's schedule if weekly paid time is not violated).

And the grand idea of course would be Google Docs style completely concurrent editing. That of course comes with other challenges besides the engineering effort (e.g., two people editing the same day and agent and some overlapping activities - "hey, my changes just disappeared").

Tagging @Paul Wood​ on the Product Management side. I know we always like feedback on possible enhancements.

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.

thanks for the tag Jay.

thanks for the feedback @James Weibel to help further with the conversation, and it sounds like you might have already done this, could I ask that you take a look at the Ideas lab and upvote, comment or create new ideas. 

There are probably many enhancements and ideas around this. I did a quick search in Ideas Lab, but did not find anything great. There are a couple that mention full on 'locking' of an agent's entire schedule when someone is editing them. I am not a fan of locks like that (e.g., Suzy Supervisor locks Bob's schedule while making edits, gets sick and leaves without unlocking) for several user experience reasons.

I know others have asked for more information on the conflict (e.g., inform the user who made the modification that got in first and when it was made).

Then there is also potentially reconsidering at what level the conflict granularity is with maybe some rules (e.g., allow a conflicting change to an agent's schedule if weekly paid time is not violated).

And the grand idea of course would be Google Docs style completely concurrent editing. That of course comes with other challenges besides the engineering effort (e.g., two people editing the same day and agent and some overlapping activities - "hey, my changes just disappeared").

Tagging @Paul Wood​ on the Product Management side. I know we always like feedback on possible enhancements.

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.

thanks for the tag Jay.

thanks for the feedback @James Weibel to help further with the conversation, and it sounds like you might have already done this, could I ask that you take a look at the Ideas lab and upvote, comment or create new ideas. 

There are probably many enhancements and ideas around this. I did a quick search in Ideas Lab, but did not find anything great. There are a couple that mention full on 'locking' of an agent's entire schedule when someone is editing them. I am not a fan of locks like that (e.g., Suzy Supervisor locks Bob's schedule while making edits, gets sick and leaves without unlocking) for several user experience reasons.

I know others have asked for more information on the conflict (e.g., inform the user who made the modification that got in first and when it was made).

Then there is also potentially reconsidering at what level the conflict granularity is with maybe some rules (e.g., allow a conflicting change to an agent's schedule if weekly paid time is not violated).

And the grand idea of course would be Google Docs style completely concurrent editing. That of course comes with other challenges besides the engineering effort (e.g., two people editing the same day and agent and some overlapping activities - "hey, my changes just disappeared").

Tagging @Paul Wood​ on the Product Management side. I know we always like feedback on possible enhancements.

Two schedule changes for the same agent across will result in the second person's attempt to publish failing with the conflict. Different agents in the same scenario will allow both people to publish their respective changes. The granularity of the conflict detection is at the agent level and not agent+day. A change to an agent on one day can be important for the second person to know about before they alter a different day (e.g., the second person's change might result in too much weekly or period pay time or days).

You can mitigate to a large part by communicating as a scheduling team (Genesys Cloud chat with a specific room for the team) and avoid times between publishes (e.g., don't make 30+ minutes worth of edits and then publish) and thus narrow any potential conflict windows.