A spreadsheet has no permissions: whoever has the file sees everything. The first application a business builds for itself often has just a login, and behind it everyone sees everything as well. Until an apprentice sees the purchase prices, a former employee can still log in, or a customer finds another customer’s orders in the portal.
Permissions are not a sign of distrust towards staff. They make sure everyone sees what they need for their work and that a change remains traceable. This article describes how roles and permissions are set up in business software - and why the question has gained new weight with AI assistants.
Check in the system, not in the screen
Many applications hide buttons. The warehouse worker does not see the “change price” button, so he cannot change the price - or so the assumption goes. In fact the screen only checks what it displays. Anyone who knows the address behind it, or points another program at the same data, gets it anyway. In a spreadsheet that is the hidden tab; in a web application it is the interface the screen itself uses.
The rule: every check that matters happens where the data lives. The screen may hide buttons to keep things tidy - but the system must say no when a request arrives that is not allowed. Self-built applications frequently lack exactly this, see built it yourself with AI.
Roles rather than individual permissions
Give every employee individual permissions and you soon lose track: “Ms Meier may see invoices but not cancel them, except for one particular customer.” After a while nobody remembers why. Better to have roles that describe the work, and staff who are given roles. One person can hold several roles - the head of sales, for instance, Sales and Approval.
Typical roles in a business:
| Role | Works with | Stays hidden |
|---|---|---|
| Sales | customers, quotes, orders, selling prices | purchase prices, wages, payments |
| Warehouse | items, stock, delivery notes, locations | prices, payments |
| Accounts | invoices, payments, documents, reminders | technical documents |
| Management | reports, approvals, settings | nothing, but every change is logged |
| External partners | only their own projects or orders, reports | all other customers and orders |
Two kinds of permission are hidden in that table. Permissions on functions: who may write invoices, who may change prices? And permissions on data: the field sales rep sees customers, but only their own; the partner sees projects, but only theirs. The second kind is the harder one and exactly what every customer portal needs.
Deputies and leavers
Holidays, sickness, a colleague working from home: as soon as permissions are set up properly, the question of deputies follows. Two approaches have proved themselves. A time-limited role - Mr Schulz is given the Accounts role until a set date, after which it lapses by itself. Or a deputy rule - Mr Schulz stands in for Ms Meier, sees her tasks, and everything is logged under his name. What does not work: sharing the password. Then the log is worthless.
For approvals above a limit you set, the four-eyes principle helps: whoever creates a purchase order does not approve it themselves.
When someone leaves, the account is blocked, not deleted - the log should still know the name. Settle who creates accounts, who blocks them and how that person learns of a departure. That is a gap more often than the technology is.
The log: who changed what
Every change to a price, delivery date, address or approval is recorded: who, when, old value, new value. Not for surveillance, but so that questions can be answered: why is there a different price here? Who moved the date? The log replaces the question in the corridor.
Changes are logged, not every read - otherwise the log becomes unreadable. The exception is data where access itself must be traceable, such as personnel records. Which requirements on documents and retention apply to you should be settled with your tax adviser and your data protection officer.
What this has to do with AI assistants
An AI assistant that answers questions about your data (“Which orders are overdue?”) accesses the same data as your staff. The question is: with whose permissions? If the assistant works with a shared account that sees everything, everyone who asks it sees everything - the apprentice the wages, the partner the other customers.
The permission check therefore has to apply to the AI exactly as it does to people: the assistant works with the permissions of the person asking and receives only data and documents that person could open themselves. With documents this matters most, because filing there is usually less orderly than in the ERP: how AI reads your documents. And it is one more reason why permissions must live in the system and not in the screen: an AI does not use a screen.
How to proceed
- Write down the roles as the business actually works - no more than a handful to begin with.
- For each role, note what it sees, what it changes and what stays hidden. A table like the one above is enough.
- Name the data where the individual row matters: own customers, own projects.
- Settle deputies and leavers before the first holiday comes round.
- Decide what gets logged.
- Check whether your system can do it: an ERP or inventory system usually can, a spreadsheet that has grown or a self-built application usually cannot.
When building an application of your own, this is the part nobody wants to look at and that nonetheless has to be there first. We develop on ElbDesk, the foundation we build on: sign-in, roles and permissions come with ElbDesk, and what gets built is the part that makes your business what it is.
