Two shifts and each man is bound to one
"I will have two shifts and I will bind one man to A and another to B, and if it changes I want a request and an approval."
What is really being asked
Two outcomes, and they are served by two different screens that do not talk to each other.
- Bind a man to a shift, so his punches are measured against that shift's clock. This is done through the policy chain, not through a shift screen.
- Make a change require a request and an approval. This is Shift Change Request, and you must be honest with the client about what approving it achieves: it records and approves the decision, and it changes no measurement. Somebody still has to make the change.
This is the opposite kind of client from two shifts and nobody is bound to one. Read that page too: it is the same machinery seen from the other side, and the comparison is what makes both make sense.
What you need in place first
- Time Template - one per shift, with its clock window and its weekend days.
- Calendar - one per shift, each with a Calendar Working Time line naming its template over the dates.
- Employee Policy Profile - one per shift, each naming its calendar.
- Employee Organization Assignment - every man on one of the two profiles.
- An approval route configured for the shift change request, so the approval actually goes to somebody.
Do this
Build the two shifts as time templates.
SHIFT-A, Time In 06:00, Time Out 14:00.SHIFT-B, 14:00 to 22:00. Each template has seven weekday lines, one per day, and you tick Weekend on the day or days that are off. Set Tolerance Time In to the grace the client allows, in the factory usually 10 minutes.A night shift is allowed: put Time Out earlier than Time In and the screen rolls the end to the next day for you.
Build a calendar per shift. Calendar
FACTORY-A, and on its Calendar Working Time tab one line with Date From, Date To and Time TemplateSHIFT-A. ThenFACTORY-Bthe same way withSHIFT-B. Lines may not overlap, and the screen refuses them: "Calendar - Line ID: 2 overlaps with Line ID: 1".Build a policy profile per shift, each naming its own calendar, on Employee Policy Profile. Everything else on the two profiles is usually identical.
Bind each man. On Employee Organization Assignment, put Rashid on the Shift A profile and Imran on the Shift B profile. This is the binding. Nothing else binds a man to a shift.
Optionally record the plan as well. Shift Pattern describes the shape of a rotation: a Cycle Length in days and a line per day naming a time template or marked Off Day. Shift Roster then assigns that shape to a list of employees over a date window, with a Cycle Start Date. Two rotating crews are two roster documents on the same pattern with different Cycle Start Dates.
Do this if the client wants the plan written down and printed. Understand that it drives no measurement and no pay.
Set up the request. When Imran is to move to Shift A for a day, he raises a Shift Change Request: Employee and Transaction Date are both required, then either the new Time Template or the day ticked Off Day. Covered By records who is taking his place on a swap. Remarks carries the reason.
The screen refuses the obvious mistakes: "A day marked off cannot also carry a time template", "Enter the new time template, or mark the day off", "An employee cannot swap a shift with themselves", and a second request on the same day for the same man.
Then make the change by hand. This is the step nobody expects, so put it in the client's own procedure document. An approved shift change does not re-measure the day. If the change is permanent, open a new organization assignment on the other policy profile from the change date. If it is for one day only, the day will be measured against his normal shift, and the correction belongs on Exemption Request so the Late is paid as present.
What approving a shift change does, exactly
It is read in two places, and in both of them it is only counted: the Time Management pending-approvals tile, and an "open requests" column on the Shift Board tile. Nothing else reads it.
So, in plain words for the client:
- It does give him a record, an approver and an audit trail.
- It does not change the clock the day is measured against.
- It does not edit the roster.
- It does not reach payroll.
A rejected request can be raised again on the same date. A pending one cannot.
Where two clients differ
| Bound, with an approval | Nobody bound | |
|---|---|---|
| Time Templates | Two, one per shift | One, if the shifts are never distinguished |
| Calendars | Two | One |
| Employee Policy Profiles | Two | One |
| What binds the man | His organization assignment | Nothing |
| Changing a shift | Shift Change Request for the approval, plus a new assignment for the effect | Nothing to change |
| Month-end per-shift count | Correct | Meaningless |
| Admin cost | One assignment per permanent move | None, and the lateness figures are wrong |
How you prove it worked
- Open Employee Attendance for Imran on a worked day. Schedule Time In must read 14:00. If it reads 06:00 he is on the wrong policy profile.
- Do the same for Rashid and expect 06:00. Two men, two different schedule times, from one screen, is the proof the binding works.
- Raise a shift change request and approve it. Then re-open the attendance for that day. Schedule Time In has not moved, and that is correct behaviour, not a fault. Confirm the client has been told.
- Move a man to the other profile from the first of a month and check the schedule time changes from that date and not before it.
What will go wrong
- The client is told that approving a shift change moves the man. It does not. He discovers it when a whole shift reads eight hours late for a month.
- The permanent move is made by editing the existing organization assignment instead of adding a new one. The history is lost and, if payroll has already run over those dates, the screen refuses: "Date From cannot be changed: payroll has already been processed between 01-Nov-2026 and 30-Nov-2026".
- The shift pattern and roster are built first and treated as the configuration. They are the plan. The calendar is the configuration.
- One day's swap is handled with an assignment change. Do not. Two assignments a day is unmanageable. Use the exemption for the one day.