Module-level permissions break on the very first request
The most common access model looks like this: a user has a «Requests» checkbox, so they work with requests. The problem is that «working with requests» is at least four different actions: viewing, creating, approving and deleting.
A procurement officer should create requests but not approve them. A director should approve them but has no reason to create any. An accountant sees every request but changes none. A single «Requests» checkbox describes none of these cases.
That is why in BPM a permission is granted per action, not per section. There are well over a hundred separate permissions, and this is not complexity for its own sake — it is the minimum at which roles become meaningful.
A role is not a job title
They are easy to confuse, but they must not be merged.
A job title answers «who is this person in the org chart»: chief accountant, head of procurement. Titles are used in approval rules — «the request is approved by the requester's department head».
A role answers «what does this person do in the system»: creates requests, maintains reference data, closes deliveries. One person can hold several roles.
The practical consequence: when someone goes on holiday, you change the participant in the approval chain, not their role. When their area of responsibility changes, it is the other way round.
Start with three roles, not fifteen
A typical rollout mistake is trying to describe every possible combination of access at once. A month later there are twenty roles in the system, half of them used by a single person, and nobody remembers how «Procurement 2» differs from «Procurement extended».
What works:
- Create three or four base roles: requester, approver, procurement, administrator.
- Give each the minimum set of permissions that lets the person do their job.
- Extend only on a concrete request — when someone actually hits a limit.
A role created «for the future» almost always turns out to be unnecessary.
Organization isolation is not the same as permissions
If the system holds several legal entities, role permissions do not stretch across them. Data belonging to different organizations is separated at the platform level: a user from one company physically cannot retrieve another company's request, even with every checkbox ticked on their role.
This matters in a holding structure. The «Director» role in a subsidiary and the «Director» role in the parent company are the same set of permissions but a completely different scope of data.
A consolidated report across all organizations is still possible — but only for someone explicitly granted platform-level access.
Test access by scenario, not by checklist
The permission matrix in the interface shows which role has which permissions. That is convenient for configuration but poor at catching mistakes.
Mistakes are caught by scenario: create a test user with the role and walk through their typical day. Create a request, send it for approval, try to open someone else's, try to delete one. Five minutes of this finds more than half an hour of staring at checkboxes.
And check separately what the person cannot do: more often than not the problem is not missing permissions but extra ones.
The history of access matters as much as access itself
Settings change: someone was promoted, someone got temporary access while a colleague was away. Six months later nobody remembers why a manager has delete rights.
That is why every action in the system — including changes to roles — is recorded with its author and timestamp. During an audit, «who granted this access and when» should not turn into an investigation.
Want to review your role structure? Get in touch — we will show how it maps into the system during a demo.