Users & Permission Groups
How do we control who can use which applications and act on which records?
User accounts are provisioned from employee records, and what each account may do is granted through permission groups — bundles of application and privilege grants bound to positions in the org chart. Whoever holds the seat holds the access.
Where the control sits
Outside the organization
Accounts provisioned from employment
Creating access starts from the employee record and links the sign-on account back to it — no orphan accounts.
Permission bundles, not per-user lists
Groups carry application and privilege grants; administration manages bundles, not thousands of individual toggles.
Bound to positions
Grants attach to positions-in-unit, so access follows the org chart through every personnel change.
License-scoped grants
A group can only grant what the organization’s license includes — gating is structural, not procedural.
Read-only on expiry
An expired license downgrades privileges to read-only instead of cutting access to records outright.
InsideThe record inside Admin
How it works
The employee record is the source of truth for people. Granting someone access provisions their sign-on account and links it back to their employment record, and that one identity signs into every application in the suite — one account, one login, every module the organization licenses.
Permission groups are the unit of administration. A group bundles application access and per-privilege grants, is scoped by the organization’s license so only licensed modules can be granted at all, and binds to positions-in-unit rather than to named individuals. Assigning access means binding a seat to a group — turnover changes who holds the seat, not the grants.
Enforcement happens at sign-in: the user’s applications, privileges, and administrative flags are materialized into their session from the license and group configuration. If the organization’s license has expired, privileges downgrade to read-only rather than locking work out entirely. The full position-based access model is documented under identity & access.
What this touches
- Identity & access
The canonical description of the position-based access model these screens administer. - Organization & positions
The seats permission groups bind to are defined in the org model. - Document Management
File and folder rights use the same grant targets — positions, employees, partners. - Report Designer
Report and dashboard visibility attaches to the same positions and partners. - Human Capital Management
Employee records are where account provisioning begins.
See users & permission groups running in continON.
A guided walkthrough on a sanitized demo tenant — this capability inside its module, on the shared platform.