Two colleagues agreeing to exchange shifts is a proposal. The manager still needs to check both affected shifts and the rest of the current roster before deciding whether the change can work.
This guide follows one two-way swap. It starts with an approved roster and ends with a recorded decision and, when approved, a checked roster change and communication. SW-028 is an original fictional example. A one-way offer, absence or time-off request needs its own process.
Identify the exact shifts being exchanged
Give the request an ID and record the current approved roster version. For each leg, capture the shift ID, date, start and end time, time zone, outlet, role, current person and proposed person. Similar labels such as “Tuesday morning” can hide different times or locations.
Keep the operational record limited to what the review needs. Person codes and references to restricted records are enough here; personal or medical reasons for asking to swap do not belong in the shared worksheet.
Review both people in both directions
Record each person’s agreement, then verify availability against their other assignments. Check the observed task sign-off for the role each would take, and any supervision that would be required. Agreement alone does not demonstrate availability or competence.
Review overlapping work across outlets and the time needed to move between locations. Refer working-time, rest and pay questions to the responsible review process, recording its outcome and reference. This guide supplies no legal-hour limits, payroll calculation or automatic clearance.
Worked example: SW-028 against roster R4
At Outlet A, manager M1 reviews SW-028 on 8 November 2026 at 12:00 IST. R4 is the current approved roster. P1 and P2 have both agreed to the proposal under AG1 and AG2 and have observed counter sign-off under TR1 and TR2.
The two proposed legs look straightforward until M1 checks the other assignments. R4 also assigns P2 to OTHER-7 at Outlet B on 10 November from 10:00 to 12:00 IST.
| Leg | Shift and outlet | Date and time (IST) | Approved person in R4 | Proposed person |
|---|---|---|---|---|
| L1 | SHIFT-A, Outlet A counter | 10 Nov 2026, 08:00–12:00 | P1 | P2 |
| L2 | SHIFT-B, Outlet A counter | 11 Nov 2026, 08:00–12:00 | P2 | P1 |
A conflict stops this proposal
P2 would be assigned to two outlets from 10:00 to 12:00 on 10 November, a two-hour overlap. The other shift must not disappear from the review merely because it is at another location. Moving P1 into the second leg does not resolve P2’s first-leg conflict.
M1 declines this exact proposal at 12:00 and retains R4. No new roster version is issued. The further work-arrangement and payroll reviews were not completed because the conflict already stopped the proposal; the decline is not evidence those other checks passed. Both people and the shift lead are notified at 12:10 under NT1.
A different proposal gets a new request linked to SW-028. Preserve the declined request and its reason rather than editing it until it appears approved.
Recheck if the roster changes during review
The review belongs to a specific current roster version. Immediately before the decision, confirm that version is still current. If another approved request changed an affected person, shift or connected assignment, recheck both legs against the new version.
Record the roster reviewed, who checked it and when. An earlier agreement or successful conflict check cannot establish that a later roster still supports the exchange.
Approval still needs an applied change
For an approved request, record the approver, time, scope and any conditions. Then update both legs in the authoritative roster, identify the resulting version and have the change checked against the approved request. Until that happens, record implementation as pending; an approval entry alone does not change a manual roster.
Tell both people and the affected shift leads which version applies and when. Record the communication evidence and any acknowledgement your process requires. A pending notification or unresolved application error remains visible. Use the usual shift handover process for operational details rather than creating a second competing roster.
A later cancellation or correction needs a new dated decision and linked history. Do not erase the earlier approval, applied version or communication record.
Keep the method separate from software behaviour
Microsoft’s Shifts documentation gives a concrete example of requests being reviewed by a manager, with approval or denial, a notification and a schedule update on approval. It supports keeping those events distinct. The manual worksheet here does not perform any of those actions.
SW-028, the two-leg checks and the roster-version review are original operational examples. No Microsoft installation or Keystonne scheduling capability is assumed.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 10 complete
From reading to doing
Shift Swap Review
Use Shift Swap Review for one two-way request. It has 2 shift-leg rows, 8 review checks, 6 communication rows, 6 history events and 6 follow-ups. The summary separates the decision, source roster, resulting roster and implementation status. All fields are manual: the sheet does not detect conflicts, calculate legal hours, update a roster or send notifications. Record evidence for both legs and retain unfinished checks. For a declined request, show that the current roster remains unchanged. For an approved request, keep implementation open until the authorised changes have been applied, verified and communicated through the required process. Extend the history if needed and copy the sheet for a different request.
Open the Shift Swap Review tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- Manage shift requests and time off in Shifts (Microsoft Support) ↗
Retrieved 8 November 2026. Primary software example distinguishing a request, manager decision, notification and schedule update. Used as workflow context only, not legal guidance, a product tutorial or a Keystonne capability claim. SW-028 and its manual controls are original fiction.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.