Designation-Aware Access Control for Real Org Charts
Four roles cannot describe an organisation that has HR Directors, Payroll Officers and Fleet Managers. OPPERIQ layers designations and permissions on top.
By OPPERIQ Engineering · Platform Team
Most workforce software ships four roles: administrator, manager, employee and perhaps HR. Real organisations have HR Directors, Payroll Officers, Procurement Officers, Internal Auditors and Fleet Managers, and each of them needs a different slice of the same system. Forcing that structure into four roles produces either over-permissioned administrators or a support queue full of exception requests.
Roles, designations and permissions
OPPERIQ resolves access from three inputs. The role in the access token establishes the baseline. The employee's designation elevates them into a functional domain, so a Finance Manager or a Payroll Officer gains finance access without being made a system administrator. On top of that sit 80 granular permission codes, grouped into reusable sets and assignable per user with explicit grants and denials.
- Baseline roles for employees, managers, reviewers and administrators.
- Designation-derived access for HR, finance and IT functions.
- 80 permission codes across people, organisation, security, HR, finance, procurement, payroll, attendance, leave, tasks and tracking.
- Permission groups for common job shapes, with per-user overrides for the exceptions.
Why this reduces configuration work
Because designations already exist in the employee record, most access is correct the moment someone is onboarded. Administrators configure the exceptions rather than building a permission matrix per customer, and the same resolution logic runs behind the API — so the interface never offers an action the backend will refuse.