Shift Swap Policy Template With Separate Approval Gates

Copy this shift swap policy before accepting requests

Copy the table below into your operating procedure and request record. It is an adaptable operating policy, not legal advice. The policy settings and request fields form one reusable artifact: retain the settings and complete a new request record for each proposed change.

Policy setting or request field	Copyable text
Policy owner	[Scheduling manager or role]
Scope	[Teams, roles, and locations covered]
Submission channel	[Approved channel]
Request deadline	[Locally selected deadline]
Urgent escalation contact	[Role and contact method]
Policy rule	Workers may propose a replacement or reciprocal exchange. Worker agreement, eligibility review, manager approval, and schedule confirmation must be recorded separately. Until the approved change is reflected in the published schedule and communicated to affected workers, the existing assignment remains in effect. If the assigned worker cannot attend, use the absence escalation procedure immediately rather than treating the pending swap as coverage.
Request	[ID, submission timestamp, original worker, original shift date, start, end, location, and role]
Replacement	[Proposed worker and reciprocal shift details, if applicable]
Worker agreement	[Each worker's response and timestamp]
Eligibility	[Reviewer, review timestamp, role, location, credentials valid throughout the assignment, availability, conflicts, projected hours, rest review, and results for each affected assignment]
Approval	[Authorized manager, pending or approved or rejected, decision timestamp, and reason]
Confirmation	[Schedule update owner, affected assignments, update timestamp, notification recipients, delivery or acknowledgment status, and unresolved issues]
Policy maintenance	[Review owner, effective date, review cadence, and revision record]

This separation follows a documented distinction, not just a preference for more fields. In Microsoft Shifts, a teammate accepts or declines a swap request. Acceptance sends it to the manager for final approval; approval updates both shifts and notifies both workers.

Microsoft calls a transfer without a reciprocal shift an offer, and available request options depend on team settings. The template above uses one operating record for either arrangement. It does not claim that Microsoft provides every proposed field or that every scheduling system follows the same sequence.

Illustrative product concept using example data. This depicts assignment checks, not a swap approval screen or proof that every template field is built into the product.

Set eligibility rules before workers arrange coverage

Complete the policy settings before opening the request channel. A deadline should leave enough time for your actual review and communication process, with an urgent route for requests that arrive too late. Neither the template nor the cited guidance establishes a universal submission deadline.

Assign an eligibility reviewer and specify where that person gets the evidence. A worker saying “I can cover” establishes willingness, not authorization for the role, current credentials, or a workable rest period. Missing evidence leaves eligibility unresolved; a failed requirement blocks approval under this policy.

For each eligibility field, define the check and its evidence:

• Role and location: Check the proposed assignment against the worker's authorized roles and locations using the designated personnel or assignment record.
• Credentials: Check the required credential and its validity throughout the assignment, rather than checking only whether it is valid on the request date.
• Availability and conflicts: Inspect existing assignments and recorded unavailability. Include other locations managed by the same scheduling operation.
• Projected hours: Review the resulting hours against applicable requirements, agreements, and your approval rules. Document any required additional authorization.
• Rest and workload: Examine adjacent shifts, consecutive work periods, workload, and recovery time using the applicable local standard.

For a reciprocal exchange, complete these checks for both resulting assignments. A replacement can be eligible for the first shift while the original worker is ineligible for the shift received in return. A single “eligible” checkbox hides that distinction unless the underlying record identifies both assignments.

The UK Health and Safety Executive's good practice guidelines recommend controlling overtime and shift swapping while considering workload, consecutive work periods, and recovery. This is UK safety guidance, not a statement of United States legal requirements. Adapt the policy to applicable requirements, employment agreements, and local operating constraints.

Keep the process usable for workers. They should submit the assignment details and proposed replacement through the approved channel, not interpret credential rules or calculate the manager's staffing exposure themselves. The reviewer owns the eligibility decision and records the evidence used.

Reject this agreed swap because the replacement is ineligible

The following completed request is hypothetical. Assume the assignment requires a credential valid throughout the shift and that neither worker agreement nor manager discretion overrides that requirement. All other eligibility checks pass under the assumed local rules.

Completed request record: SW104

Request field	Completed example
Request	SW104; submitted October 12, 2026, at 09:00 local time; Worker A; October 15, 2026, 07:00 to 15:00; Site A; credentialed role.
Replacement	Worker B; no reciprocal shift.
Worker agreement	Worker A requested the change at 09:00. Worker B agreed at 09:15 on October 12.
Eligibility	Scheduling coordinator reviewed at 10:00 on October 12. Role, location, availability, conflicts, projected hours, and rest checks pass under the assumed local rules. The required credential expires October 14, before the assignment. Overall result: ineligible.
Approval	Scheduling manager rejected at 10:10 on October 12 because the required credential will not be valid for the assignment.
Confirmation	Scheduling coordinator recorded no assignment change at 10:12. Worker A remains assigned. Both workers were notified at 10:15 and acknowledged at 10:20. If Worker A cannot attend, escalate through the absence procedure and seek another eligible replacement.

Worker B's acceptance is still worth recording. It explains why the request reached review, but it does not cure the failed credential check. The manager closes the proposed replacement as rejected rather than leaving an agreed request in a vague pending state.

If renewed credential evidence later becomes available, route it through another documented review. Do not overwrite the rejection or quietly edit the assignment. Preserve the original decision and identify the subsequent request or revision so the record explains what changed.

Close approved requests only after the schedule is updated

Approval records permission to change the assignment. Confirmation records whether the assignment actually changed and whether affected workers received the new instructions. Treating those as the same event leaves room for an approved request to sit beside an unchanged schedule.

The authorized manager should record the decision, timestamp, and reason. If the proposed shift, replacement, or relevant worker information changes before approval, return the affected eligibility checks to review. Agreement to one assignment is not agreement to a different date, location, or role.

The schedule update owner then completes the change using authorized scheduling access. For a reciprocal exchange, inspect both resulting assignments. Save the resulting assignments in the published schedule, then record the update timestamp, affected workers, and any unresolved issue in the confirmation field.

Keep communication states distinct:

• Notification sent: The update was issued through the approved channel.
• Delivery recorded: The channel reports delivery, where that information is available.
• Worker acknowledged: The worker explicitly confirmed receipt through the designated method.

These are recommended record distinctions, not a claim that every scheduling product tracks them natively. If your system cannot capture one of them, designate an approved record location and an owner rather than assuming the event occurred.

Name an escalation owner for an approved request whose schedule update or communication fails. Under this template, the existing assignment remains authoritative until the approved change is published and communicated. The escalation owner must tell affected workers which assignment applies while resolving the exception, and activate the absence procedure if the assigned worker cannot attend.

Microsoft Shifts documents schedule updates and notifications following approval. Use that as an example of a defined workflow, not proof that your current system behaves identically. Test the actual saved schedule and communication results before adopting the policy.

Keep directed swaps separate from open shift bidding

For this policy, a swap is a proposed change to an existing assignment involving a specified replacement or reciprocal exchange. Bidding is different: eligible workers request available shifts under published rules for eligibility, the request window, approval, and final awards. The Teambridge shift bidding guide covers that separate workflow.

The distinction determines the next action. If a worker proposes a named replacement, review that directed request. If no replacement is available, use your open shift process to seek coverage rather than marking the original swap as approved.

Teambridge Open Shifts is an operational option for worker shift release requests, directed swaps with manager approval, and final assignment updates on the live schedule. Eligibility rules, approval rules, review queues, and notifications depend on configuration. The page explicitly excludes unrestricted reciprocal worker trading.

The product page establishes capability scope, not detailed implementation instructions. Before using it for this policy, confirm required access, where each decision is saved, what changes the published schedule, and who handles update or notification failures. Workforce assignment tools do not replace your determination of applicable credential, employment, or safety requirements.

Publish the policy after assigning owners and testing one request

Roll out the policy only after the people responsible for approval and confirmation can complete the same record. Workers should not have to guess whether a supervisor's message counts as permission or whether someone else will update the schedule.

1. Fill the local settings. Specify scope, submission channel, deadline, urgent contact, and the requirements used for eligibility review.
2. Assign responsibility and access. Name the eligibility reviewer, authorized approval role, schedule update owner, and exception owner. Confirm each can reach the records needed for the task.
3. Test the rejected request. Run hypothetical SW104 through the process. Verify that worker agreement does not change the assignment and that the rejection reaches both workers.
4. Issue the policy and maintain it. Record the effective date, review owner, and review cadence. Confirm workers know both the request channel and the urgent absence channel.

The HSE fatigue guidance recommends monitoring policies through records of working time and swapping. The measures below are editorial recommendations for this policy, not metrics prescribed by HSE or promised performance improvements.

Choose a reporting window and keep its definition consistent. Track median decision time from submission to manager decision for requests decided within that window. Report unresolved requests separately so quick decisions do not hide an aging queue.

Track requests still pending at their scheduled start as a count and a share of all requests affecting shifts that start within the window. For reciprocal exchanges, flag the request if it remains pending when either affected shift begins. Group rejection reasons for rejected requests decided in the same window.

Finally, count approved requests missing schedule confirmation and report them as a share of requests approved during the window, using a stated reporting cutoff. Inspect the underlying records before changing the policy: repeated eligibility failures may call for clearer rules, while incomplete confirmation points to an ownership or execution problem. A swap process is finished when the assignment and the communication are settled, not when someone agrees to help.