on-call

[andreahart]

We have always had issues with our on-call schedules and shifts, but it seems more  prominenent since we upgraded to Yokohama.

1. The main issue is that when a shift manager tries to change a current shift or rotation, the changes are not saved. We usually end up deleting the schedule and starting over, which means there is no historical data, and maybe that's ok. But is that by design?

2. There seems to be shift overlap warnings for overlaps that do not exist, which makes us think there is residual data that is not clearing when a shift if is modified. (This only happens when we allow shift overlaps, but we only do that because otherwise we cannot create a shift at all.)

3. We are not convinced that the ServiceNow On-call interface is syncing with the Service Operations Workspace interface.  Are there any known issues with this?

[andreahart]

Hello Mark.
Thanks for your response.

This turned out to be user error.
There were some date conflicts in some of the forms that I was not aware of.

[kaushal_snow]

Hi @andreahart ,

Update Shifts via the On Call Schedule UI (not by recreating) to retain historical data and redesign overlapping patterns into sequential o -call segments to avoid backend conflicts.

You can Use the Resolve Gaps & Conflicts tool in On Call Scheduling to clean up any leftover shift artifacts.

For more, check Yokohama patch notes, some PRBs may resolve your concerns.

You can check below articles for more details:

https://www.servicenow.com/docs/bundle/yokohama-it-service-management/page/administer/on-call-schedu...

https://www.servicenow.com/docs/bundle/yokohama-release-notes/page/release-notes/quality/yokohama-pa...

https://www.servicenow.com/docs/bundle/yokohama-prbrn/page/release-notes/dfrn2-yokohama-onebundle/PR...

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

[andreahart]

Thanks. I'll try that.