GRAPH BUG - Copied and Pasted Shift Schedules show as from the copied person on API

Question

GRAPH BUG - Copied and Pasted Shift Schedules show as from the copied person on API

Joel Silveira 0

Hello,

We use the Graph endpoints to do our workforce management and we have been experiencing some issues with the endpoint below when making the request, everytime we run the ingestion it returns the data from the schedules as it belongs to the same user, e.g we have 12 shifts set on the day, on the web UI it shows under each employee but in the API data it return all 12 shifts belonging to the same person.

https://graph.microsoft.com/v1.0/teams/{team_id}/schedule/shifts

We usually copy and paste the same shift for everyone and we perform the changes needed, and it was working perfectly before, but since May 1st the shifts returned belongs to the same person.

I found a workaround that would be create the first shift for each person manually and then copying from their own shifts, but this could not be best for us because we have more than 8k employees and doing that everytime for the OPS team might not be acceptable.

Mitchell Randle 5 Reputation points

2026-05-06T20:05:30.08+00:00

I am facing the same issue in a similar workflow.

In the meantime, I may have found a slightly faster workaround to the one you've described: If you create a template shift within "open shifts", copying and pasting from there will allow the correct user ID to be inherited for the get shifts call. This method allows one central place to copy and paste from with no regard to whose schedule you are copying from or whose schedule you are pasting into.

1 answer

Your answer

Mitchell Randle 5 Reputation points

2026-05-06T20:05:30.08+00:00

I am facing the same issue in a similar workflow.

In the meantime, I may have found a slightly faster workaround to the one you've described: If you create a template shift within "open shifts", copying and pasting from there will allow the correct user ID to be inherited for the get shifts call. This method allows one central place to copy and paste from with no regard to whose schedule you are copying from or whose schedule you are pasting into.

Answer 1

The behavior described is not configurable from the client side and is not documented as expected behavior for the GET /teams/{teamId}/schedule/shifts API.

The schedule/shifts endpoint is documented simply to “Get the list of shift instances in a schedule” for a given team, and there is no indication in the documentation that copying/pasting shifts in the Shifts UI should cause all returned shifts to appear as belonging to a single user, nor that this behavior changed as of a specific date.

Given that:

The API contract is to return the list of shift resources for the team schedule.
The issue started recently (after May 1st) and is tied to UI copy/paste behavior.
There is no documented parameter or workaround in the Graph shifts or PowerShell cmdlets that would alter user assignment semantics for copied shifts.

This aligns with a service-side regression or product bug rather than a client misuse.

Recommended actions:

Treat this as a product bug in the Shifts/Graph integration.
Open a support ticket with Microsoft, providing:
- The affected tenant and team IDs.
- Example shift objects from GET /teams/{teamId}/schedule/shifts showing all 12 shifts assigned to the same userId.
- Screenshots or evidence from the Shifts UI showing the same shifts correctly distributed across users.
- The approximate time when the behavior changed (May 1st) and whether it reproduces consistently when using copy/paste.
Continue using the temporary workaround (creating the first shift per user manually, then copying from that user) only as a short-term mitigation until Microsoft confirms and fixes the issue.

There is no supported client-side way in the documented APIs or PowerShell cmdlets (such as New-MgTeamScheduleShift / New-MgBetaTeamScheduleShift or Update-MgTeamScheduleShift / Update-MgBetaTeamScheduleShift) to override or correct this behavior automatically once the service is returning incorrect userId assignments; it must be addressed on the service side.

References: