- What's the logic?
The base schedule re-rollout logic determines what happens when you roll out a base schedule more than once over the same time period, the same employee(s) and using the same base schedule week and weekdays. If you re-roll out over partly the same period or for some, but not all, employees, the re-rollout logic will be applied for that specific part of the period and/or for those specific employees.
What's the logic?
If you roll out your base schedule multiple times over the same time period in Schedule but make edits in your base schedule between rollouts, the next rollout will roll out the edits made in your base schedule.
However, if you've somehow edited the base schedule shift(s) in Schedule, the next rollout won't roll out the updates you've made to that or those shifts.
Edits in Schedule not re-rolled out by Base Schedule
- Editing of shift duration (by editing start and/or end time of shift)
- Editing of shift type
- Addition, deletion or editing of break
- Moving of shift (to other date and/or other start and end time)
- Shift swap with other employee
- Un-assigning of shift
- Assigning of shift to an employee
- Previously un-assigned shifts
- Shifts previously assigned to another employee
- Moving of shift from one section to another
- Change of project to which a shift is assigned
- Change of cost centre to which a shift is assigned
- Change of employee agreement (for the same assignee)
- Addition/removal of task to/from a shift
- Edit of task on a shift
- Change in duration of task
- Moving of task (to other date and/or other start and end time)
- Addition of one or several approved punch(es) to the shift
Edits in Schedule re-rolled out again by Base Schedule
- Deletion of shift
- Conversion of shift into absence shift
- Note, however, that if prior to adding the absence over top of the shift you've made an edit to shift as described in 1) - 15) above, the logic applying to the edits described in 1) - 15) will apply.
- Approval of the absence to which a given absence shift belongs.
A word regarding absence shifts
- If you delete an absence and choose to convert the absence shifts into actual shifts again, and those shifts were coming from a base schedule, then those shifts will still have their connection to the base schedule - meaning that the logic described in this article will still apply.
How do I know I'm about to re-rollout a base schedule?
Quinyx will only show the re-roll out warning message (see image below) if there's an overlap of employees and time period between current roll out and a previous one.
Example: If you roll out 15 employees the first time, and then one of those 15 employees is rolled out a second time during the same or partly the same time period, the warning message is displayed:
Why does Quinyx have this logic in the first place?
Answer: The reason for the re-rollout logic is that it's common practice for changes sometimes a change needs to me made by you as a user to the schedule template - i.e. base schedule - after it's been rolled out. In cases where those changes also need to be reflected in the rolled out period, the re-rollout logic allows you to ensure that's done by re-rolling out. Early user feedback made us improve the logic to ensure that changes made to rolled out shifts in the actual Schedule weren't overriden when due to re-rollouts.
Why are deleted shifts re-rolled out?
Answer: Initially, deleted shifts weren't rolled out anew, but this posed a problem in the cases where users had, for instance, rolled out the wrong base schedule over a certain wrong period. As the option of making a copy of said base schedule, emptying the initial one of its shifts only to the re-rolling it out is rather cumbersome, the current functionality was implemented.
Why are shifts with approved punches not rolled out anew whereas absence shifts of approved absences are?
Answer: Shifts with approved punches aren't re-rolled out as the approved punch indicates that the user - either the manager or both the employee and manager - has certified that the punch for that specific shift is correct; editing those shifts as of a re-rollout would therefore run the risk of creating incorrect payroll data. However, for absences and their absence shifts, the interdependencies between the two are of another kind than that of shifts and their punches, making a re-rollout more appropriate. If you've got feedback on this behavior, please share it with us using the Send us feedback button.