RosterApps Rule Sets

Details

Rule Sets in RosterApps control a great deal of how the application behaves in various situations with employees and shifts, and they contain the majority of configurable logic that is used in the managing of your workforce.

Rule Sets are established at the Company Admin level and have their own tab in the top navigational bar at the top of every RosterApps web page.

When a Company Admin accesses the Rule Sets tab, they will see several different types of Rule Sets. These are:

Shift Rule Sets – This is the largest rule set in RosterApps, with many dozens of individual settings. As the name would suggest, this rule set governs the behavior of shifts and employees belonging to a given work group. Among the settings are to be found things like: minimum rest hours, maximum work hours, can employees trade shifts, or the minimum percentage of base schedule hours to be worked in a week.

Paid Time Off Rule Sets – This rule set governs employees and Paid Time Off requests and in which situations they can make PTO requests. RosterApps can require that a given employee have the relevant accrual hours to cover a given PTO request, preventing your managers from having to field invalid requests. Other settings here include the limiting of accrual rollover for anniversaries or year changes, whether an employee can cancel a PTO request or approved PTO shift, or if a Supervisor can override conflicts on behalf of making a request on behalf of an employee.

UTO Rule Sets – Unpaid Time Off rule sets govern an organization’s policies regarding time off that isn’t compensated. Unpaid time off requests are different than Unscheduled time off requests, in that Unpaid time off requests are made on shifts on a given employee’s calendar. Unscheduled time off requests are utilized in the event the organization utilizes the Schedule Builder (as opposed to utilizing Bid Packages).

VTO Slot Rule Sets – Voluntary Time Off Slot rule sets govern whether and how the organization uses VTO slots (these function kind of like a negative shift object). A Company Admin can set minimum amount of time before a given shift a VTO Slot can be claimed, or a maximum amount of time from the shift start, or whether a VTO Slot claim can be cancelled.

Security Rule Sets – These rule sets have to do with the mobile application (not currently supported) and whether or not the trade board and calendar should be displayed for those mobile users.

Rounding Rule Sets – These rule sets have to do with automatic rounding of received clock punches from integrated work groups in RosterApps. Punch clocks transmit InPunches/OutPunches to RosterApps using the API, and when received, these rule sets enable you to control automatic rounding of those punches if your labor policies allow for it. One can control grace periods before and after scheduled shift starts/stops and which directions the rounding should follow in which situations.

Dependability Rule Sets – These rule sets involve which settings your various employees follow if you are utilizing RosterApps Dependability system. Settings here involve which user role can affect dependability points, and the setting up and specification of triggers and exceptions for incurring points and whether/when they fall off. Disciplinary actions can also be specified for point thresholds, once reached by a given employee.

Meal Break Rule Sets – This rule set involves the specification of meal breaks and their handling. A Company Admin can specify whether automatic handling is based on continuous hours worked or a floating or fixed meal break, Min/Max duration for punches and whether or not there is a pay penalty code for meal break violation minutes.

Overlap Rule Sets – This rule set has to do with Time and Attendance handling of shift overlaps. A Company Admin can specify whether the rule type is a shift classification component comparison, or a shift classification rank, and then the individual component and preferred comparison result.

Rule Sets in RosterApps are specified at the Work Group level. This means that unless an individual employee is set to be following an exceptional rule set specifically, they will by default follow the Rule Set settings of their assigned work group at the time.

Location Admin -> Work Groups (tab) -> (find given work group) -> Edit (link)

It is best practice to have all employee users be set to “(none – use work group rule)” on their individual Rule Set pages:

Location Admin -> Employees (tab) -> (find given employee) -> Edit (link) -> Edit Rule Sets (link)

This way, in the event of a policy change, you need only affect the work group’s settings, as opposed to however many employees individually that happen to be in the work group.

Not only does RosterApps enforce Rule Set logic on employee users, but because the logic is enforced at the Work Group level, and Work Groups derive their schedules from Bid Packages, the individual shifts derived from those bid packages have the Work Group’s Rule Set logic enforced on them as well. This means that not only can one enforce logic on a given employee, but also on a given shift – and both the shift and the employee, simultaneously. In fact, RosterApps can evaluate the logic between different shifts from different work groups being traded between two employees belonging to a third and fourth work group – each shift and employee observing a different Rule Set. This is achieved by evaluating the settings of the different Rule Sets involved, and determining the most-limiting value, and using that for purposes of determining the validity of a given action. So, if one has an employee on a probationary rule set, you don’t need to worry about them being able to trade with any other work group (or any other employee) – if that probationary employee is set to be following an exceptional rule set that disallows shift trades.

Additionally, RosterApps enforces all the settings of the Rule Sets simultaneously. A given action by an employee user -- for example, a two-way trade of a block of shifts between EmployeeA and EmployeeB -- would be prevented if the result would have EmployeeB violating a minimum rest in window setting, even if everything else about the shift is perfectly valid and in compliance. This is a powerful capability, because there are dozens of settings in RosterApps, some seemingly enforcing similar things. You can specify rule set settings to be used in conjunction with each other, enabling fine-tuning of policy being reflected in RosterApps. For example, you want to allow certain work group members to be able to pick up Open shifts that may result in overtime, but not more than 12 hours extra per week, and not if the extra hours would result in less than a 12-hour rest period every 48 hours. As you can imagine, a great deal of granular control is possible through the use and tuning of Rule Sets in RosterApps.

Rule Sets can also be set to be observed for a work group (or individual) for an indefinite period of time, or one can set the start and end of observance times. Practical use of this might be setting a period of blackout activity around a holiday or an expected seasonal operations change. Additionally, this capability can be used for purposes of disciplinary rule set onset and falloff automatically. For example, an offending employee can have a start date for observance of a disciplinary rule set, and the Location Admin can (at that same time) establish an end date. RosterApps will enforce the Rule Sets in observance as of the StartTime(s) of the shift(s) in question, so any shift that would fall within such a period would have the offending employee observing that disciplinary rule set, but shifts before or after that observance period would be governed by whichever Rule Set settings the employee was/is set to follow. If the employee to be disciplined should be restricted until some to-be-determined-date, one has only to **not** set the end date, and the exceptional rule set will be observed until it is changed or scheduled to change manually.

Lastly, changes to an existing Rule Set setting will be applied immediately upon confirming the change/edit. They will **not** however, apply those changes retroactively. Best practice for making changes to existing Rule Sets (unless fairly minor) is to establish an identical Rule Set, then make the intended change, and have that rule set be observed by a smaller sub-set of the larger work group. One should then run that changed Rule Set on the test sub-set for a while to evaluate, then move it over to be observed by all members of the work group once satisfied with the enforcement. If changes are made to existing rule sets, it is recommended to use the Rule Set Description field (if applicable) at the bottom of the edit Rule Set page to notate these adjustments.