Poland Weekly Rest Rule
The Poland Weekly Rest Rule automates compliance with Poland's 35-hour continuous weekly rest requirement by performing a number of key functions.
This extension allows you to perform Poland's 35-hour rest calculation anchored to the first day of the settlement period rather than a floating or rolling week.
You will be able to:
- Create schedule rule copies: The extension automatically generates schedule rule copies at the start of each settlement period, typically the first day of every month, based on the Location and Base Schedule Rule combinations defined in the Cross Reference Table (CRT).
- Assign rule copies: The extension assigns these newly generated schedule rule copies to active employees who already have a valid base schedule rule assigned and whose location and rule combination matches an entry in the CRT.
- Remove outdated or invalid rule copies: The extension validates each employee's assigned rules and removes any invalid, expired, or duplicate Boomi-created rule copies that fall outside of the defined CRT or no longer align with the employee's base rule or location.
- Clean up the system: The extension automatically inactivates Boomi-created schedule rule copies that are older than a configurable number of days (default value: 365 days), ensuring system cleanliness.
Considerations and limitations
The base schedule rule used for copy generation must include at least one REST rule row in its configuration. The extension does not create copies for rules that do not include a REST rule.
The extension processes only employees who are active on the integration run date. Employees with inactive or terminated statuses are excluded.
Monthly and weekly settlement periods are supported, based on the configuration defined in the CRT.
The base schedule rule configuration is copied without modification. Only the anchor date and week start day are adjusted to align with the first day of the settlement period.
Schedule rule copies created by the extension follow a defined naming convention that appends a space and the date in DD.MM.YY format (for example, Warsaw Rest 01.12.25). This convention distinguishes integration-generated rules from manually configured ones.
Copies are created only when valid for the current run. If a copy already exists from a previous run, it is not recreated, ensuring idempotent behavior.
If the run date falls on the first day of a settlement period, the copy for that period is created and assigned. If the run occurs on any other date, copies are generated starting with the next settlement period.
If an employee's employment expiration date falls within the look-ahead window, no copies are created or assigned for dates beyond the expiration.
If an employee's location changes, the corresponding Location and Rule combination must exist in the CRT. If it does not, no copies are created or assigned for that location.
All future baseline rules within the look-ahead window are evaluated. If a matching CRT entry exists, those rules are considered valid and are copied and assigned accordingly.
The integration automatically removes invalid or expired copies that no longer match the CRT configuration or that fall outside the defined horizon window.
If an employee's location changes while retaining the same Base Schedule Rule, the new location's schedule rule copy will be assigned on the execution date that matches the location change date. An exception applies during the first execution after a location change, where the extension will assign the new location's copies. However, in subsequent runs, any extra or mismatched copies will be removed automatically.
If the Assignment or Unassignment API call encounters duplicate Schedule Rule IDs in the same request, the API call will fail. The system allows identical Rule IDs for the current and next schedule rule assignments, but if any other duplicate Rule ID appears more than once in a single request, the API call returns an error.
Before you start
-
Hyperfind, Location, and Employee IDs: Create and configure all three.
-
Location:
Ensure that the Location name mentioned in the Cross-Reference Table (CRT) is correct.
The Location name is case-sensitive.
-
-
CRT: Ensure the CRT is correctly configured with all possible combinations of rules.
-
Base Schedule Rule Set:
Must be present in the application and assigned to an employee.
Ensure that the correct Base Schedule Rule for the integration execution is assigned to an employee.
Must have at least one Rest rule configured.
The Base Schedule Rule Set name must be 20 characters or less.
Must not have duplicate entries that contain the same combination of Location and Base Schedule Rule.
-
User experience
Use cases
The following sections contain tables that describe the configuration and the outcome of running the integration for each use case. For example, in the first use case:
- The employee has the initial Warsaw Weekly Rest Schedule Rule Set already assigned in People Information effective September 1st, 2025.
-
The CRT contains a valid combination of Location and Base Schedule Rule Set, and that combination is also valid for the specified employee.
-
After the integration runs, the additional 6 Schedule Rule Sets are assigned to the same employee in People Information.
Each subsequent use case follows a similar format.
Creating future copies for one Location and one Base Rule
This use case considers a scenario where a manager wants to assign future copies of an existing, valid base rule for one location.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Krakow* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Krakow/Cashier | 2025.10.01 |
| Rule | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.09.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/09/2025 | 31/12/2025 |
| Warsaw Weekly Rest 01.01.26 | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Warsaw Weekly Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Warsaw Weekly Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Warsaw Weekly Rest 01.05.26 | 01/05/2026 | 31/05/2026 |
| Warsaw Weekly Rest 01.06.26 | 01/06/2026 | Forever |
Creating duplicate future copies for one Location and one Base Rule — no change
This use case considers a scenario where a manager wants to assign future copies of an existing, valid base rule for one location. However, the integration was already run once, so the six future copies already exist for the specified location and time period. As a result, no change occurs.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Krakow* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Krakow/Cashier | 2025.10.01 |
| Rule | Effective Date | |
|---|---|---|
| Warsaw Weekly Rest | 2025.09.01 | |
| Warsaw Weekly Rest 01.01.26 | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Warsaw Weekly Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Warsaw Weekly Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Warsaw Weekly Rest 01.05.26 | 01/05/2026 | 31/05/2026 |
| Warsaw Weekly Rest 01.06.26 | 01/06/2026 | Forever |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/09/2025 | 31/12/2025 |
| Warsaw Weekly Rest 01.01.26 | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Warsaw Weekly Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Warsaw Weekly Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Warsaw Weekly Rest 01.05.26 | 01/05/2026 | 31/05/2026 |
| Warsaw Weekly Rest 01.06.26 | 01/06/2026 | Forever |
Creating a missing future copy for one Location and one Base Rule
This use case considers a scenario where a manager has assigned future copies of an existing, valid base rule for one location. In this case, the integration was already run once, so the six future copies were created for the specified location and time period. Someone manually deleted one of the six future copies—it does not matter which one. In this scenario, running the integration again will recreate the missing future copy and make no other changes.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Krakow* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Krakow/Cashier | 2025.10.01 |
| Rule | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.09.01 |
| Warsaw Weekly Rest 01.01.26 | 2026.01.01 |
| Warsaw Weekly Rest 01.02.26 | 2026.02.01 |
| Warsaw Weekly Rest 01.04.26 | 2026.04.01 |
| Warsaw Weekly Rest 01.05.26 | 2026.05.01 |
| Warsaw Weekly Rest 01.06.26 | 2026.06.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/09/2025 | 31/12/2025 |
| Warsaw Weekly Rest 01.01.26 | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Warsaw Weekly Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Warsaw Weekly Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Warsaw Weekly Rest 01.05.26 | 01/05/2026 | 31/05/2026 |
| Warsaw Weekly Rest 01.06.26 | 01/06/2026 | Forever |
Invalidating all future copies for one Location and one Base Rule
This use case considers a scenario where a manager wants to invalidate all future copies of an existing, valid base rule and its future copies for one location.
When the integration is run, all future copies are deleted and only the base rule remains assigned to the employee.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Noida* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Krakow/Cashier | 2025.10.01 |
| Schedule Rule Set | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.09.01 |
| Warsaw Weekly Rest 01.01.26 | 2026.01.01 |
| Warsaw Weekly Rest 01.02.26 | 2026.02.01 |
| Warsaw Weekly Rest 01.03.26 | 2026.03.01 |
| Warsaw Weekly Rest 01.04.26 | 2026.04.01 |
| Warsaw Weekly Rest 01.05.26 | 2026.05.01 |
| Warsaw Weekly Rest 01.06.26 | 2026.06.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Rule | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/09/2025 | Forever |
Creating future copies for one Location and two Base Rules with employee expiration
This use case considers a scenario where a manager wants to assign future copies of two existing, valid base rule sets for one location utilizing an employee expiration. As a result, future copies are assigned only until the month of April, 2026.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Warsaw* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2025 |
| Poland/Warsaw* | Krakow Labor Rest | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.11.15 |
| Rule | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.10.01 |
| Krakow Labor Rest | 2026.01.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
-
Employee Status Inactivated Date — 15/04/2026
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/01/2025 | 30/11/2025 |
| Krakow Labor Rest | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest 01.12.25 | 01/12/2025 | 31/12/2025 |
| Krakow Labor Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Krakow Labor Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Krakow Labor Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
Creating future copies for multiple Locations, one Base Rule, and Week Settlement Period
This use case considers a scenario where a manager wants to assign future copies of one existing, valid base rule for multiple locations utilizing the WEEK settlement period.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| * |
Lubin Weekly Rest | 2 | WEEK | 12 | 01.10.2025 |
| Location | Effective Date |
|---|---|
| Poland/Krakow/Cashier | 2025.10.14 |
| Poland/Warsaw/Cashier | 2026.01.07 |
| Rule | Effective Date |
|---|---|
| Lubin Weekly Rest | 2025.10.14 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Lubin Weekly Rest | 15/11/2025 | 25/11/2025 |
| Lubin Weekly Rest 26.11.25 | 26/11/2025 | 09/12/2025 |
| Lubin Weekly Rest 10.12.25 | 10/12/2025 | 23/12/2025 |
| Lubin Weekly Rest 24.12.25 | 24/12/2025 | 06/01/2026 |
| Lubin Weekly Rest 07.01.26 | 07/01/2026 | 20/01/2026 |
| Lubin Weekly Rest 21.01.26 | 21/01/2026 | 03/02/2026 |
| Lubin Weekly Rest 04.02.26 | 04/02/2026 | 17/02/2026 |
| Lubin Weekly Rest 18.02.26 | 18/02/2026 | 03/03/2026 |
| Lubin Weekly Rest 04.03.26 | 04/03/2026 | 17/03/2026 |
| Lubin Weekly Rest 18.03.26 | 18/03/2026 | 31/03/2026 |
| Lubin Weekly Rest 01.04.26 | 01/04/2026 | 14/04/2026 |
| Lubin Weekly Rest 15.04.26 | 15/04/2026 | 28/04/2026 |
| Lubin Weekly Rest 29.04.26 | 29/04/2026 | 12/05/2026 |
Creating future copies for two Locations, two Base Rules — second Base Rule in effect after Location change
This use case considers a scenario where a manager wants to assign future copies of two existing, valid base rule for two locations where the second base rule comes into effect after the location change.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Warsaw* |
Warsaw Weekly Rest | 1 | MONTH | 6 | 01.01.2025 |
| Poland/Krakow* | Krakow Labor Rest | 1 | MONTH | 3 | 01.03.2026 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.10.14 |
| Poland/Krakow/Cashier | 2026.01.01 |
| Rule | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.10.14 |
| Krakow Labor Rest | 2026.02.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 14/10/2025 | 30/11/2025 |
| Krakow Labor Rest | 01/02/2026 | 28/02/2026 |
| Warsaw Weekly Rest 10.12.25 | 01/12/2025 | 31/12/2025 |
| Warsaw Weekly Rest | 01/01/2026 | 31/01/2026 |
| Krakow Labor Rest 07.01.26 | 01/03/2026 | 31/03/2026 |
| Krakow Labor Rest 21.01.26 | 01/04/2026 | 30/04/2026 |
| Krakow Labor Rest 04.02.26 | 01/05/2026 | Forever |
Creating future copies for one Location, two Base Rules — existing future copies are invalid and new rule set is added for the future
This use case considers a scenario where a manager wants to assign future copies of two existing base rules for one location where the existing future copies of the Krakow Labor Rest rule are invalid and a new rule set is added for the future.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Lublin* |
Lubin Weekly Rest | 1 | MONTH | 6 | 01.01.2026 |
| Poland/BLR* | Krakow Labor Rest | 1 | MONTH | 6 | 01.03.2026 |
| Location | Effective Date |
|---|---|
| Poland/Lublin/Cashier | 2025.10.14 |
| Rule | Effective Date |
|---|---|
| Krakow Labor Rest | 2025.10.14 |
| Krakow Labor Rest 01.01.26 | 2026.01.01 |
| Krakow Labor Rest 01.02.26 | 2026.02.01 |
| Krakow Labor Rest 01.03.26 | 2026.03.01 |
| Lubin Weekly Rest | 2025.03.15 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set | Start Date | End Date |
|---|---|---|
| Lubin Weekly Rest | 15/03/2026 | 31/03/2026 |
| Lubin Weekly Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Lubin Weekly Rest 01.05.26 | 01/05/2026 | 31/05/2026 |
| Lubin Weekly Rest 01.06.26 | 01/06/2026 | 30/06/2026 |
| Lubin Weekly Rest 01.07.26 | 01/07/2026 | 31/07/2026 |
| Lubin Weekly Rest 01.08.26 | 01/08/2026 | 31/08/2026 |
| Lubin Weekly Rest 01.09.26 | 01/09/2026 | Forever |
| Krakow Labor Rest | 14/10/2025 | 14/03/2026 |
Remove all invalid future copies for one Location and one Base Rule
This use case considers a scenario where a manager wants to remove all invalid future copies of an existing, valid base rule for one location.
When the integration is run, all invalid future copies are deleted and only the base rule remains assigned to the employee.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Warsaw* |
Rule ABC | 1 | MONTH | 6 | 01.01.2026 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.10.14 |
| Schedule Rule Set | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.10.14 |
| Warsaw Weekly Rest 01.01.26 | 2026.01.01 |
| Warsaw Weekly Rest 01.02.26 | 2026.02.01 |
| Warsaw Weekly Rest 01.03.26 | 2026.03.01 |
-
Run Date — 15/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Rule | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 14/10/2025 | Forever |
Create future copies for three assigned Locations when only two Locations are present in the CRT and for two Base Rules with one being a Boomi copy
This use case considers a scenario where a manager wants to create future copies of a more complex situation, where three Locations are assigned to the employee but the CRT only contains two of the Locations and does not have a combination for the Warsaw Location and the Krakow Labor Rest rule.
When the integration is run, the base Krakow Labor Rest rule is assigned from May, 2026 until the end of time since the employee has Poland/Warsaw/Cashier assigned beginning this month, and that location is not present in the CRT.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| Poland/Krakow* |
Krakow Labor Rest | 1 | MONTH | 6 | 01.01.2025 |
| Poland/Lubin* | Krakow Labor Rest | 1 | MONTH | 6 | 01.01.2025 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.01.01 |
| Poland/Krakow/Cashier | 2026.01.01 |
| Poland/Lubin/Cashier | 2026.03.01 |
| Poland/Warsaw/Cashier | 2026.05.01 |
| Schedule Rule Set | Effective Date |
|---|---|
| Warsaw Weekly Rest | 2025.08.01 |
| Warsaw Weekly Rest 01.10.25 | 2025.10.01 |
| Warsaw Weekly Rest 01.11.25 | 2025.11.01 |
| Krakow Labor Rest | 2026.01.01 |
-
Run Date — 28/10/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Rule | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 01/11/2025 | 31/12/2025 |
| Krakow Labor Rest | 01/05/2026 | Forever |
| Krakow Labor Rest 01.04.26 | 01/04/2026 | 30/04/2026 |
| Krakow Labor Rest 01.03.26 | 01/03/2026 | 31/03/2026 |
| Krakow Labor Rest 01.02.26 | 01/02/2026 | 28/02/2026 |
| Krakow Labor Rest | 01/01/2026 | 31/01/2026 |
| Warsaw Weekly Rest | 01/08/2025 | 30/09/2025 |
| Warsaw Weekly Rest 01.10.25 | 01/10/2025 | 31/10/2025 |
Remove all future copies of Base Rule when the Base Rule has been deleted
This use case considers a scenario where an administrator wants to remove all future copies of a base rule that has been manually deleted.
When the integration is run, all future copies of the base rule are deleted and only the base rule and any other valid, already-assigned rules remain assigned to the employee.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| * |
Warsaw Weekly Rest | 1 | MONTH | 3 | 01.01.2025 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.10.15 |
| Schedule Rule Set | Effective Date |
|---|---|
| $GLOBALSHIFTS | 2025.10.15 |
| Warsaw Weekly Rest 01.12.25 | 2025.12.01 |
| Warsaw Weekly Rest 01.01.26 | 2026.01.01 |
| Warsaw Weekly Rest 01.02.26 | 2026.02.01 |
-
Run Date — 16/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Rule | Start Date | End Date |
|---|---|---|
| Warsaw Weekly Rest | 14/10/2025 | 14/10/2025 |
| $GLOBALSHIFTS | 15/10/2025 | Forever |
Inactivating old Base Rules
This use case considers a scenario where a manager wants to inactivate old base rules that are no longer applicable.
When the integration is run, the old base rules are inactivated and only valid base rules and their future copies remain active.
| Location | Base Schedule Rule Set | Settlement Period Frequency | Settlement Period Type | Future Iterations Period | Effective Start Date |
|---|---|---|---|---|---|
| * |
Warsaw Weekly Rest | 1 | MONTH | 13 | 01.10.2025 |
| Location | Effective Date |
|---|---|
| Poland/Warsaw/Cashier | 2025.10.01 |
| Schedule Rule Set |
|---|
| Warsaw Weekly Rest |
| Warsaw Weekly Rest 01.01.22 |
| Warsaw Weekly Rest 01.01.23 (Inactive) |
| Warsaw Weekly Rest 01.01.24 |
| Warsaw Weekly Rest 01.01.26 |
| Warsaw Weekly Rest 01.02.26 |
| Warsaw Weekly Rest 01.03.26 |
| Warsaw Weekly Rest 01.04.26 |
| Warsaw Weekly Rest 01.05.26 |
| Warsaw Weekly Rest 01.06.26 |
| Warsaw Weekly Rest 01.07.26 |
| Warsaw Weekly Rest 01.08.26 |
| Warsaw Weekly Rest 01.09.26 |
| Warsaw Weekly Rest 01.10.26 |
| Warsaw Weekly Rest 01.11.25 |
| Warsaw Weekly Rest 01.11.26 |
| Warsaw Weekly Rest 01.12.25 |
-
Run Date — 16/11/2025
-
FutureDaysLookAhead — 365
-
InactiveRuleSetDays — 365
| Schedule Rule Set |
|---|
| Warsaw Weekly Rest |
| Warsaw Weekly Rest 01.01.22 (Inactive) |
| Warsaw Weekly Rest 01.01.23 (Inactive) |
| Warsaw Weekly Rest 01.01.24 (Inactive) |
| Warsaw Weekly Rest 01.01.26 |
| Warsaw Weekly Rest 01.02.26 |
| Warsaw Weekly Rest 01.03.26 |
| Warsaw Weekly Rest 01.04.26 |
| Warsaw Weekly Rest 01.05.26 |
| Warsaw Weekly Rest 01.06.26 |
| Warsaw Weekly Rest 01.07.26 |
| Warsaw Weekly Rest 01.08.26 |
| Warsaw Weekly Rest 01.09.26 |
| Warsaw Weekly Rest 01.10.26 |
| Warsaw Weekly Rest 01.11.25 |
| Warsaw Weekly Rest 01.11.26 |
| Warsaw Weekly Rest 01.12.25 |
Boomi extension setup
- Get the URL, User, and Password for the APIGatewayServer.
- Install and attach the iPack.
Note: For more information, see the Deploy Integration Packs to your Atom topic.
-
Open the Integration Template Designer: Select Main Menu
. Note: If prompted, enter your Username and Password. Click Tap Log in. -
Make sure that the Account is correct. If not, select the right account.
- Select the Deploy tab > Integration Packs.
- From the list in the left column, search for and select the PolandWeeklyRestRule integration. Note: If the integration does not display, select Browse Integration Packs to search for and select the iPack.
-
Click Tap Install.
-
From Unattached Environments, select the environment in which to deploy the integration process for the selected integration. Click Tap the double-left arrows button
.
-
- Configure the Poland Weekly Rest Rule integration settings
- Select the environment
- Select the Manage tab > Runtime Management.
- Select your environment.
- Select environment extensions
- In Administration, click tap Environment Extensions.
- In Process Filter, click tap the magnifying glass
. It can take several seconds before the button becomes active. -
Scroll to and select the integration pack: .
- Select the environment
- Configure connection settings
Caution: If you select Use Default for the connection settings and process properties, ensure that Value is blank. If Value is not blank, that value overrides the default value whether or not Use Default is selected or cleared. Example: If the default value is abc, but Value shows xyz, the integration uses xyz regardless of the setting of Use Default.
- Select Connection Settings.
-
From the Connection dropdown list, select and configure the following:
Connection Settings
Connection Settings for the integration
Setting
Required
Actions
PolandWeeklyRestRule_iPack_v1_APIGatewayServer
Required
To change the default API gateway server:
- Clear Use Default.
- Enter the URL to the server.
Example:
<tenantURL>/api
PolandWeeklyRestRule_iPack_v1_Configuration_CRT
Required Enable Override.
PolandWeeklyRestRule_iPack_v1_Locale_CRT
Required Enable Override.
- Configure process properties
- Select Process Properties. Caution: Do not edit the default values of the AuthenticationProperties. By default, cookies are enabled and set the values for authentication properties.
-
Select PolandWeeklyRestRule_iPack_v1_CRTConfig to set process properties that must be configured before the integration can run. This main process starts the integration process and handles errors.
Process properties
Process properties
Process property name
Column header value
_PolandWeeklyRestRule_iPack_v1_CreateScheduleRuleSet_CRT Locations,Base Schedule Rule Set,Settlement Period Type (WEEK/MONTH),Settlement Period Frequency,Future iterations,Effective Start Date (DD.MM.YYYY) _PolandWeeklyRestRule_iPack_v1_Locale_CRT Parameter Name,Locale Policy,Value,Description
- Select Process Properties.
Configure the Poland Weekly Rest Rule integration
After the integration is deployed, complete the following configurations before you utilize this integration.
Cross reference tables
To make a cross-reference table available for integration processes, populate the table with data.
- If more than one row matches a reference value, the first match is the output value.
- If no match is found, the output value can be null, or the integration can produce errors.
PolandWeeklyRestRule_iPack_v1_CreateScheduleRuleSet_CRT: the configuration source for the extension, storing valid combinations of Location and Base Schedule Rule along with their settlement details, frequencies, and effective dates to determine which schedule rule copies should be created and assigned to employees.
| Column name | Description |
|---|---|
| Locations | The employee's assigned work site used by the extension to determine which schedule rule applies during rule creation and assignment. |
| Base Schedule Rule Set | The original schedule rule configuration in the application that serves as the source for generating compliant copies based on Poland's 35-hour weekly rest requirement. |
| Settlement Period type (Week/Month) | How often the rest period resets; for example, monthly or weekly settlement periods. |
| Settlement Period Frequency | How many weeks or months each settlement cycle covers (for example, 1 = every week or month, 2 = every two weeks or month). |
| Future Iterations | The number of future iterations or settlement cycles the integration creates and attaches to the employee. |
| Effective Start Date (DD.MM.YYYY) | The date from which the CRT row becomes active and eligible for rule creation and assignment. |
| Locations | Base Schedule Rule Set | Settlement Period Type (Week/Month) | Settlement Period Frequency | Future Iterations | Effective Start Date (DD.MM.YYYY) |
|---|---|---|---|---|---|
| Poland/Krakow* | Warsaw Weekly Rest | MONTH | 1 | 6 | 01.01.2026 |
| Poland/Lubin* | Warsaw Weekly Rest | WEEK | 2 | 6 | 01.01.2026 |
PolandWeeklyRestRule_iPack_v1_Locale_CRT: Stores customized labels, messages, and error key configurations for the Poland Weekly Rest Rule extension, following the locale policy in the employee's preferred language. Data must be inserted in chronological order, with default values pre-configured.
| Column name | Description |
|---|---|
| Parameter Name | The parameter name defined in the Poland Weekly Rest Rule messages process. |
| Locale Policy |
Locale Policy. Note: You can use an asterisk (*) as a wildcard, but put the less-restrictive locale policy names at the bottom of the table because the integration scans cross-reference tables from the top.
|
| Value |
Message shown in Additional Details, or value of the label defined in the Run Summary section. |
| Description |
The description that is shown in Additional Details. |
- Localization of integration extensions remains optional, but is supported.
- The cross-reference table (CRT) holds all messages represented with standard English labels; these apply to all locales when the Locale is set to a wildcard (*).
- Some or all messages can be translated by adding lines to the table in their preferred translation for specific locales. Messages for the most commonly used Locale Policy should be defined at the top of the CRT.
- Names of the parameters in the CRT column "Parameter Name" must be used as is. If any parameter value needs to be localized for a different Locale Policy, copy the "Parameter Name" with the * Locale Policy, add a new row to the CRT with the appropriate Locale Policy, and then add the localized values in the Message (or Value) and Description CRT columns.
- Do not enter values in the CRT column "Description" if it is blank.
- Do not modify placeholders (<>) or the configurable values that are included in the CRT column "Message" (or "Value").
| Parameter name | Locale Policy | Value | Description |
|---|---|---|---|
| Error_MessageDefaultError | * | Error encountered during integration run. Refer to Process Reporting for more details. | Default error message for the process. |
| Error_MessageForAPIError | * | API error caused integration failure. See error message below: | Default API error message for the process. |
| Error_MessageHyperfindNotFound | * | Hyperfind is not found in control parameter. | The Hyperfind was not found in the control parameter. |
| Error_MessageForRestRuleNullError | * | No Schedule Rule Set found in employee scheduler. | An error thrown when the Rest Rule is empty. |
| Error_MessageForInvalidSettlementPeriod | * | Invalid Settlement Period Type | The Settlement Period Type mentioned in the CRT is invalid. |
| Error_MessageForInvalidFreqInteger | * | Settlement Period Frequency must be greater than 0 | The Settlement Period Frequency is invalid in the CRT. |
| Error_MessageForInvalidFreqRangeWeek | * | Settlement Period Frequency for WEEK must be 1 to 52 | The Settlement Period Frequency for WEEK must be 1 to 52. |
| Error_MessageForInvalidFreqRangeMonth | * | Settlement Period Frequency for MONTH must be 1 to 12 | The Settlement Period Frequency for MONTH must be 1 to 12. |
| Error_MessageForInvalidIterationsInteger | * | Future Iterations is not a valid integer | Future iterations is not a valid integer in the CRT. |
| Error_MessageForInvalidIterationsRange | * | Future Iterations must be greater than or equal to 1 | Future iterations must be greater than or equal to 1 in the CRT. |
| Error_MessageForInvalidDate | * | Effective Date invalid or not in format DD.MM.YYYY | The specified Effective Date is invalid. The Effective Date must be provided in a DD.MM.YYYY format. |
| Error_MessageForBaseRuleSetNameMaxCharExceeded | * | Maximum character limit exceeded for Base Rule Set name | The Base Rule Set name exceeds the maximum character limit. |
| Error_MessageForMissingFields | * | Missing required fields | Required columns are missing for the specified CRT row. |
| Error_MessageForDefaultLocationAndScheduleRule | * | Applicable Location, Schedule Rule Set - | Default message for location and schedule rule set name to be used in other messages. |
| Disqualify_MessageForMissingCRTRows | * | CRT Row does not exist. | That CRT Row does not exist for the specified schedule rule set and location combination. |
| Error_MessageForInactiveBaseRule | * | The Base Rule is Inactive - | The specified Base Rule is inactive. |
| Error_MessageForNoRestRuleInBaseRule | * | The Base Rule does not have any Rest Rule - | The specified Base Rule does not have any rest rule. |
| Error_MessageForConfigErrorInCopyCreation | * | Copy Schedule Rule could not be created due to the below mentioned error. Copy rule set, Error - | An error was encountered during copy rule set creation due to a configuration issue in the base rule. |
| Error_MessageForCheckFutureDaysLookAhead | * | Non-successful response received due to horizon date is not correct, it should not be empty or will be greater than 0. | Incorrect horizon date specified. |
| Error_MessageForCheckRuleInactiveOlderThanDays | * | Non-successful response received due inactive date should be greater than zero. | Inactive days for schedule rule inactive |
| Error_MessageForConfigErrorMultipleSameRuleSetID | * | Same Base Rule is present multiple times in employee scheduler and some copies of them are invalid | The Same Base Rule is present multiple times in employee scheduler and some copies of the rule are invalid. |
| Disqualify_MessageEmployeeNotFound | * | Hyperfind selected returned no employee records. | The specified Hyperfind did not return any employee records. |
| Error_MessageForPersonNotExist | * | Person Number does not exist | The specified person number is invalid. |
| Disqualify_MessageForCRTEffDateOutsideHorizon | * | CRT Effective Date is outside of the Horizon Date | The Effective Date in the CRT Effective Date is outside of the Horizon Date. |
Install the Poland Weekly Rest Rule integration
After the integration is deployed and the connection settings and process properties are configured, install the integration to make it available for running or scheduling.
- An integration template is the configured integration that you deploy to an Atom and then install to make available for running or scheduling.
- An installed integration is a single instance of an integration that is based on an integration template. When you install an integration, you can define parameters or set parameters to be defined when the integration is run.
- Select Main Menu
. - Click Tap Create
. - In Integration Name enter a unique name, such as
PolandWeeklyRestRule_iPack_v1. - (Optional) Enter a Description.Note: Do not select API Integration.
- (Optional) If the person who runs the integration does not have full access to integrations, select Execute Integration with System Account. This allows the integration access to all APIs in the FAP, and the relevant permissions and data, regardless of the FAP and GDAP of the person who runs the integration.
- (Optional) Select Re-Run to allow repeated runs of the integration with the same parameter values as the previous run.
- (Optional) Configure Email Notifications:
- In Skip Configuration, select None (default) to allow multiple integrations to run at the same time or with the same data without restrictions.Note: Do not select Allow Minute Interval.
- Configure Integration template and parameters:
- Make sure that the generic data access profiles (GDAP) allow access by the people who need to run the installed integration.
Run and test the Poland Weekly Rest Rule integration
- Run the integration
- Select the integration:
- Select Main Menu .
- Click Tap Run an Integration .
- Select the PolandWeeklyRestRule_iPack_v1 integration from the list. Click Tap Select.
- (Optional) Enter a unique Integration Run Name to make it easier to identify the run of the integration. Otherwise, the default name ends with a date and time stamp.
- Set parameters as follows:
- Hyperfind: Select a Hyperfind query of employees.
- Person Numbers: To process data for only a limited group of employees, enter the person numbers, as defined in the source system, each separated by a comma (
,) but no spaces.For 3 employees:
13997,15556,20012
- Select the following:
- Run Integration : If this is the first time this integration is being run.
- Re-Run: If this integration has been run before, and the status is not In-Progress, you can run the integration again without entering the parameter values again. Click Tap Yes to continue, or No to not run the integration and to return to the parameter settings.
- Wait for the confirmation that the integration completed or failed. Close the panel.
- Click Tap Refresh .
- To see details, select the integration run. Select Run Summary.
- Select the integration:
- Check the results
Status indicators
- In-Progress: The run of this integration has not yet completed.
- Completed: The integration ran successfully without errors.
- Scheduled: This integration is scheduled to run later or repeatedly.
- (Grayed out) Scheduled but Deleted: This integration is scheduled to run, but the integration template has been deleted. When it runs, it will generate an error. To prevent this error, delete the scheduled integration run.
- Completed with Errors: The integration ran successfully, but one or more records have errors. The integration run is treated as failed. If Abort on Failure is configured in an integration set, the integration set stops.
- Failed: The integration run has errors or could not run.
- To troubleshoot and resolve errors, do the following:
Check the Run Summary for details.
- To troubleshoot all types of errors, or if the Run Summary shows a large number of errors, click tap Go to Additional Details (if available), or click tap the Source File to open and examine the input source file.
- (Only for import integrations) To troubleshoot and resubmit integrations that have transactional or data errors, click tap Go to Transaction Assistant.
To check the results in more detail, do the following:
- To see detailed results, click tap the tile for the integration run.
- Click Tap Run Summary to see the results of the integration run.
Example Run Summary details
Note: The available details vary by integration and configuration.- Integration Run Name: Name of this run of the integration.
- Process Name: Name of any integration set that includes this integration.
- Integration Name: Name of the installed integration.
- Integration Reference ID: Unique identifier for this integration run (to help in troubleshooting errors).
- User: The person or user account that ran the integration.
- Integration Type: Import, Export, or None
- Start Date: Date and time when the integration run started.
- End Date: Date and time when the integration run finished.
- Status: In-Progress, Completed, Completed with Errors, or Failed.
- Records Processed: Number of records that were processed.
- Records Created: Number of records that were created.
- Errors: Number of records that failed.
- Source Files, Output File, and Error Files: For file-based import integrations, use Manage SFTP to access the source and output files on the inbound (source) and outbound (destination) SFTP folders. See the Manage SFTP topic.
- Log in to the destination system and make sure that the data has been correctly updated.
Note: You can schedule integrations and integration sets to run once later or at a recurring frequency. See the Schedule Integrations topic.
APIs
|
API name |
Type |
Resource path |
Description |
|---|---|---|---|
|
Retrieve User Preferences for Current User or Tenant Default |
GET |
/v1/commons/user_preferences/locale_policy |
This operation returns user preferences (locale policies) for the current user or tenant. |
|
POST |
/v1/commons/hyperfind/execute |
Executes a Hyperfind query by ID or qualifier, and then returns the result. | |
|
POST |
/v1/commons/persons/extensions/multi_read |
This operation returns multiple person records based on search criteria. Search criteria include personid, personnumber, jobassignmentid, username, useraccountid, and badgenumber. | |
|
POST |
/v1/commons/persons/schedule_rule_sets/multi_read |
This operation returns a list of rule set assignments for multiple employees, a date, and a context. | |
|
POST |
/v1/commons/persons/schedule_rule_sets/multi_upsert |
This operation updates rules set assignments for multiple employees, a date, and a context. | |
|
GET |
/v1/scheduling/schedule_rule_sets |
This operation returns a list of all Schedule rule sets or returns a particular rule set by name. | |
|
POST |
/v1/scheduling/schedule_rule_sets |
This operation creates a Schedule rule set. | |
|
POST |
/v1/commons/persons/schedule_rule_sets/multi_upsert |
This operation updates rules set assignments for multiple employees, a date, and a context. | |
|
PUT |
/v1/scheduling/schedule_rule_sets/{ruleSetId} |
This operation updates a Schedule rule set by ID. | |
| Submit Integration Execution Additional Details | POST | /v1/platform/integration_executions/{id}/additional_details | This operation submits all additional details related to an integration execution (API or batch) into system. |
| Update Integration Execution Details | POST | /v1/platform/integrations/update_status | This operation updates and returns the callback instance against the provided integration execution details. |
Version history
| Version | Description |
|---|---|
| 1.0 | The Poland Weekly Rest Rule Extension
automates compliance with Poland's 35-hour continuous weekly rest requirement
by performing the following key functions: Schedule Rule Creation, Assignment of Rule Copies, Validation and Copy Management, and Rule Inactivation and Cleanup. |
