eProcureAI / Platform / Access and Permissions
Access and PermissionsPermissions belong to departments rather than to people. Choose the department and the right access follows, for everyone who is there now and everyone who joins later.
This is the real screen. Org map, permission matrix and department baselines.
Every access problem starts the same way. Somebody joins, an administrator copies the settings from whoever seems similar, and nobody checks it again for three years.
Do that a hundred times and you have a permission structure no one can explain, where the fastest way to work out what somebody can do is to ask them to try it.
In eProcureAI permissions attach to departments. Finance has a baseline of fifteen permissions. Everybody in Finance inherits those fifteen, including the person who joins next month. Adding somebody is a single decision about which department they are in.
Two views of the same thing. The org map shows departments and what each one can do. The matrix shows permissions against departments, with each cell telling you whether all members have it, some members have it through an override, or nobody does.
Tapping a cell edits the baseline, which means changing what a whole department can do is one action rather than a morning of individual edits.
Sometimes one person genuinely does need something extra. That is an override, and it shows as an override rather than blending into the baseline. When an access review comes round, the exceptions are the short list rather than the whole population.
Eight of them in a typical setup, matching how the business is actually organised rather than an idealised structure.
The set of permissions everybody in that department needs. Finance carries fifteen, which is more than most because of the approval and budget work.
Adding somebody to a department gives them the baseline immediately. There is no copying from another user and hoping it was right.
Anything beyond the baseline sits on top of it and is visibly an override, which keeps the review list short.
Changing somebody's department removes the old baseline and applies the new one, so nobody carries access from a job they left.
Almost everybody should be covered by their department baseline. If most of your population needs overrides, the baseline is wrong rather than the people being unusual.
An override is a deliberate exception for one person. Because it is marked as an override rather than folded into the baseline, an access review looks at a handful of cases rather than the whole company.
When somebody asks who can approve a purchase over fifty thousand, the answer is a view rather than an investigation. That is the difference between a permission structure and a permission situation.
Three levels, taken from the product. Each one sees a genuinely different amount.
| Role | Sees | Does not see | Why it is scoped this way |
|---|---|---|---|
| Company head | Every team, workload and pending approvals across the business | Nothing withheld | Needs the whole picture to spot where work is piling up |
| Manager | Their own team's requests, workload and approvals | Other teams' work | A manager looking at nine other teams stops looking at anything |
| Team member | Their own requests and what they need to act on | Colleagues' requests | Most people only need their own work, and more than that is noise |
Scoping is not only a control question. A view that shows somebody ten times more than they need is a view they stop opening.
A baseline that is slightly too tight generates requests you can grant. One that is too broad generates nothing at all until an audit.
Overrides are the exceptions, so a review means looking at those rather than confirming that everybody in Finance is still in Finance.
Moving somebody removes the old baseline and applies the new one, which is why nobody ends up carrying access from a role they left two years ago.
When a new permission appears, deciding which baselines get it is a five minute conversation. Skipping it is how drift starts.
The matrix exports, so an access review starts from a document rather than from a request for one.
Permission departments that do not match how the company is organised will always need overrides, which defeats the point.
Permissions stay understandable when they describe a role rather than a history of individual decisions.
Decide which department somebody belongs to. That is the decision, and almost everything else follows from it.
Applies the baseline, keeps the matrix current, and cleans up when people move.
Thirty minutes is enough to map your departments and show what each person would actually see.
Book your free demoNext in the chain: The full platform