| Note: From October 1st, 2025, we introduced new plans that better reflect how our customers use Deputy: Lite, Core, and Pro. If you're an existing customer, look out for an email with all the details you’ll need. Learn more about the new plans and what this change means for you. |
This article explains how Pay Rate Builder (PRB) determines pay periods using a hierarchy, including what happens when a setting is left as default.
Before you read
- Target audience: This article is for System Administrators and users who manage payroll.
- Plan restrictions: This article applies to Core and Pro plans. Enterprise customers use separate Enterprise period settings when rules are left as default. Read about the Enterprise customer exception.
This article covers:
- How the PRB period hierarchy works
- Enterprise customer exception
-
Understanding Shared Settings visibility
How the PRB period hierarchy works
PRB determines pay periods using a hierarchy. If one layer is set to default, Deputy checks the next layer until it finds the applicable period setting.
The hierarchy order:
- Pay Rule (Local Context)
- Shared Settings
- Regular Working Hours (RWH)
- Location Settings
1. Pay Rule (local context)
The system first checks the individual pay rule to determine whether a specific period has been defined.
Best use case
This option is best for unique scenarios where one rule operates on a different period than others, such as weekly versus fortnightly overtime calculations.
Important considerations
Changing the period directly on a pay rule converts the rule into a custom pay rate, which means it will no longer receive automatic compliance updates (such as those in California).
What happens when a setting is left as default
If the pay rule period is set to default, the system proceeds to Shared Settings.
2. Shared Settings
If the Pay Rule is set to default, the system next checks the Shared Settings configured on the Pay Rules page.
Best use case
Shared Settings are useful when multiple overtime rules use the same period logic. For example, if you have 20 different overtime permutations that all share the same period logic, it is much easier to apply a shared setting than to update 20 individual rules.
Important considerations
Unlike modifying an individual Pay Rule, changing the period in Shared Settings does not trigger a custom pay rate message and does not break automatic updates.
What happens when a setting is left as default
If Shared Settings are set to default, the system proceeds to the employee's Regular Working Hours configuration.
3. Regular Working Hours (RWH)
If Shared Settings are set to default, the system checks the employee profile under the People tab for a Regular Working Hours (RWH) configuration.
How it works
If an RWH configuration exists on the employee profile, the system uses that period setting regardless of whether the overtime checkbox is enabled.
Why this behaviour exists
This behaviour is designed to preserve legacy configurations that were established before the PRB was implemented.
What happens when a setting is left as default
If no RWH configuration exists, the system proceeds to Location Settings.
4. Location Settings
If none of the above are configured, the system falls back to a Weekly period, determined by the location's "first day of the week" setting.
This is the final fallback behaviour for Core and Pro accounts.
Enterprise customer exception
Enterprise customers follow a separate fallback behaviour to the hierarchy above. If an Enterprise customer leaves their rules set to default, the system will default to the specific pay periods defined in their Enterprise settings.
Understanding Shared Settings visibility
The Shared Settings referred to above will only appear if a period pay rule exists (or other rule type that could leverage shared settings).
If you are starting from scratch, Shared Settings will not be visible until a period pay rule is added.