Planning roles and permissions in business software

Role and permission are not the same thing

A permission is a single authorisation: viewing orders, approving orders, changing prices. A role bundles permissions into a job profile: case handling, sales, accounting.

The separation is worthwhile as soon as there are more than two groups. Assigning permissions to individual people is quicker at the start and becomes more expensive with every staff change — someone then has to work out which authorisations the departed person had.

Four questions that must be answered

• Who may VIEW a record? Often the hardest question, because visibility usually depends on responsibility — own department, own customers, own region. Who may CHANGE it, and from which status onwards no longer? An approved order behaves differently from a draft. Who may APPROVE or close it? That is almost never the same group as the one that creates it. Who may DELETE it — and what does deleting actually mean? In many business applications it means: mark as invalid, do not remove — as long as retention obligations or traceability require it. For personal data, it must also be clarified when it is actually deleted.

The fourth question has a side effect that is often overlooked: if data is not really deleted, all lists and reports must know that invalid records exist. If this is forgotten in one place, deleted transactions appear in the annual statistics.

Permissions apply on the server, not in the interface

A hidden button is a usability aid, not a safeguard. Anyone who knows the address can still call up the operation. Only the check on the server is binding, and at every single access — including the ones the interface does not offer at all.

This applies particularly to lists with filters: a filter that bypasses the permission check shows, via a URL parameter, data that would never be reachable in the interface. Such places are found almost only in a review or in a test that specifically looks for them.

Where to start

Not with a permissions matrix of fifty individual permissions. A sensible approach is: name three to five roles, answer the four questions above for each, and write down the special cases instead of solving them immediately.

The special cases are where the real insight lies. If, while writing things down, you notice that a role may do different things in two departments, you model it either as two roles or as one role with a scope, such as the user's own department.