Why should installers see one tab? Role-based access that actually protects data

An installer opens the app in the morning and sees one tab: today's tasks. Not the sales pipeline, not the accounts, not the other crews. That is not a limitation of the app. It is the most important feature in it.

When I built a business management platform for a company that sells and installs made-to-order products for homes, the system had to cover everything: marketing leads, sales, quotes, orders, installation scheduling, accounting, invoices and after-sales. Nine different jobs use it. The design question was never "what can the software do". It was "what should each person be able to see".

Design the roles before the screens

The first document was a table of positions and what each one may do: an administrator with full access; managers who run orders, users and installations but cannot open the accounts; sales staff who see leads, orders and their own records; an accountant who owns payments, pricing and financial reports; an installation manager who schedules tasks and teams; a measurer who records measurements; and installers who see only the tasks assigned to them.

Every screen in the system was then built against that table, not the other way round. When a new feature was requested later, the first question was which positions get it, and that question was usually the one that shaped the feature.

A person can hold more than one position

Small businesses do not have one person per job. The owner sells, manages and approves costs. So positions are additive: a user holds a set of them, and their access is the union. This avoids the usual trap of inventing a fake "super user" role that quietly grants everything, and it means a position can be added or removed without rebuilding the person's account.

Check access per record, not just per role

Role checks answer "may a salesperson open orders". They do not answer "may this salesperson open that order". The second question is where most systems leak. A quote PDF, for example, is fetched by a storage key; if the only check is "is this user in sales", any sales rep who guesses or is sent a key can read another rep's quote.

So the platform authorises files per record. Before a quote PDF is served, the server loads the quote and asks whether this caller may see this quote: created it, is assigned to it, or holds a position that covers all quotes. The same rule governs customer documents, accounting records and after-sales tickets. It costs one database read per request and removes a whole class of quiet data exposure.

Invite-only sign-up, and nothing public

There is no sign-up page. An administrator invites a user, who sets a password from the invitation link. Accounts are tied to positions from the moment they exist, and removing someone is a single action that revokes everything. Customer documents and accounting files live in private storage and are only ever served through the authenticated API, after the per-record check above. Nothing in the system has a public URL.

Why it matters more than it looks

Access control is usually treated as a compliance box. In practice it is what lets a business put everything in one system. The owner can hand the installers an app without worrying that pricing is visible on a job site. The accountant can work in the same system as sales without the pipeline being editable from the accounts. One system, with each person seeing exactly what their job needs, is only possible because the boundaries are enforced by the software rather than by asking people to be careful.

This is the access model behind the business management platform. The system has been in production and continuous development since late 2025, with the position table still the first thing any new feature is checked against.

Common questions

What is role-based access control in business software?

Each user holds one or more positions, and each position grants access to specific screens and actions. A manager might run orders and installations but have no access to accounting; an installer sees only their own tasks. Access is decided by the software, not by trusting people to avoid pages they shouldn't open.

Why check permissions per record as well as per role?

A role check decides whether a kind of user may open a kind of thing. A per-record check decides whether this user may open this specific order, quote or file. Without the second check, anyone in the right role can reach other people's records by guessing or sharing a link.

Can one user have several roles?

Yes, and in small businesses they usually do. Positions should be additive, so a user's access is the combination of everything they hold, and a position can be added or removed without rebuilding their account.

Is a custom system more secure than an off-the-shelf CRM?

Not automatically. It is more secure when the access model is designed first and enforced on the server for every request, including file downloads. The advantage of a custom build is that the model matches how the business actually works instead of forcing the business to fit a generic one.