Skip to content
Voxbi Cockpit APIs
API Guides

Validators and managers

A validator rule defines who can approve which requests for which population. It is the outgoing approval engine: approval chains replace it, and new configuration belongs there.

What changes with approval chains

The two engines answer the same question and answer it differently, so a rule does not translate one-to-one into a chain:

Validators and managers Approval chains
Every rule matching the employee contributes its validators to one merged pool. Exactly one chain decides a request, picked by how specifically it names the employee.
No ordering. Any validator in the pool could act at any time. Steps are asked in order, and a step waits for the one above it.
The quorum was the strictest requirement among the matching rules. The number of approvals is set per step, per request type.
Oversight had to be a validator, so an overseer acting early could settle the request. Watchers are a separate concept: they never hold a request up, and only decide if given that power.
Self-approval was a per-rule switch. Self-approval is a tenant-wide list, per request type.
A request matching no rule fell back to the employee's department manager. There is no implicit fallback. A request that reaches nobody stays pending, and the coverage report shows it.

How the rules behave

Listed as Validators and managers in the menu, these rules route holiday requests, home office requests, time-point corrections, and schedule-management actions. Each rule sets the validators (employees who can approve), which request types it covers, the population in scope, and the signature requirement.

Scope decides which population the rule applies to:

Type What it targets
All employees Everyone in the PBX, across all companies (broadest).
Company Employees with active contracts in one or more chosen companies.
Department Employees with active contracts in the chosen departments.
Employees Specific named employees (narrowest).

A validator may also be listed among the validated employees. Whether their own requests are surfaced to them for approval is controlled by Can validators approve their own requests?.

Signature model comes from combining All-must-approve and Required approvals:

Model Configuration Behavior
Any one All-must-approve off, Required approvals unset First validator to act resolves. Default.
N of M All-must-approve off, Required approvals = N At least N validators must approve.
Unanimous All-must-approve on Every validator must approve.

Covered modules are toggles. A rule covering both holiday and home office applies to both. Use separate rules to give those workflows different validators.

When a request is filed, the system finds all rules matching its module and the employee's population. The union of their validators can approve, and the strictest signature requirement wins. If no rule matches, approval falls back to the default department manager.

How to move to approval chains

  1. Write down what each existing rule does: population, request types, validators, and signature requirement.
  2. Group them by population, not by rule. Several rules could cover one person, but only one chain can, so each population needs a single chain carrying the whole ladder.
  3. Turn each merged pool into ordered steps, deciding which validators belong on which step and setting the count there instead of as one number across everything.
  4. Move oversight-only validators to watchers so they stop holding requests up.
  5. Re-create per-rule self-approval as entries on the tenant-wide self-approval list, per request type.
  6. Account for anyone who relied on the department-manager fallback. Chains have no implicit fallback, so a population that no chain reaches now reaches nobody.
  7. Check the coverage report, which is the safety net the old engine had no equivalent of.
  8. Leave these rules in place while requests raised under them are still pending. A request stays on the engine that created it, so both can run side by side until the queue drains.

See also

Updated