Node

A regulation is a set of restrictions associated with a node in the hierarchy with a validity period (from–to). Each restriction defines a specific rule of a legal, collective agreement, or business type, such as the maximum daily working hours or the minimum rest between shifts. A regulation, therefore, groups several of these rules and links them to a node and a time period.

Regulations are inherited in the hierarchy: a node is subject to its own regulations plus those of all its ancestor nodes. When two regulations affect the same restriction, the one from the more specific node prevails, unless the one from the higher node is marked as non-overridable, in which case a lower layer can only redefine it if its value is more restrictive; otherwise, the value from the higher node prevails. For example, if a higher node sets the maximum shift duration to 8 hours as non-overridable, a lower level can reduce it to 7 hours, but cannot extend it to 9.

Some restrictions support more than one set of parameters: instead of a single value, it is possible to define multiple rows or blocks. Each block within a restriction has its own values applicable under different conditions: a day of the week, a time slot, a threshold, a week in the pattern…

Each user can access the information of their node and all its descendant nodes, but not that of higher nodes or parallel branches. Thus, a zone manager can see all the stores under their node, and a store manager can only see theirs. What they can view or edit within that scope also depends on the permissions of their role.

More information here.

Employees associated with a node. Each person groups their contracts, skills (what tasks they can cover and at what level), availabilities and incidents, and is the unit on which the engine generates the assignments for each day.

More information here.

Locations from the business catalog that have been activated in the node. Each location represents a position or activity (checkout, restocking, customer service…) with its required skills and level. The engine can only assign people to the tasks active in the node, and only if their skills match what the task requires.

More information here

Contract templates that can be applied to an employee. They define parameters such as regular and additional hours, calculation frequency (weekly, annual…) and can carry their own restrictions.

More information here

Used to define service schedules, needs templates, availabilities, etc. They can be defined at the node level, although some are already defined at the system level in Orquest and are available for use: working days, holidays, Monday, Tuesday, etc. Restrictions can be applied by day type.

Allows assigning specific day types to specific dates, overriding the type that would correspond by default according to the day of the week (e.g. marking a specific Monday as a local holiday). If a date has no explicit assignment, it is resolved by its day of the week. It is the reference used by some needs and planning processes to classify each day.

Historical day taken as the basis for calculating the forecast for a future day. By default, the same day of the week from the previous year is used, but it can be edited and another day can be defined when the reference day is not representative (holidays, one-off events, atypical days), so that the forecast is more reliable.

Recurring schedule or availability schemes applied to employees, defining combinations of days and time slots with their periodicity. The engine respects these when generating the schedule, limiting the possible assignments for each person to those that fit the pattern.

More information here

Not all nodes are equal; some nodes imply a higher level of complexity: the services.