Most business web applications start with a handful of people who trust each other, so everyone shares one login or gets full access. That works until the team grows, a second office opens or someone leaves on bad terms. Then the question nobody asked at the start becomes urgent: who should be able to see what, and who gets to decide?
When everyone sees everything
All-or-nothing access fails slowly. The warning signs show up long before anything goes wrong:
- Several people share one login, so the application can’t tell who did what.
- Anyone who needs to see one screen can also change prices, delete records and export your customer list.
- Only one person, often the owner, can change anything, so every small request waits for them.
- When someone leaves, you change the shared password and hope nobody else knew it.
- A customer asks why their record changed, and nobody can say who changed it, or when.
In each case the application’s rules have drifted away from how the business actually runs.
Levels that follow how the business is run
Most organisations already have a shape: an owner or operations lead, managers who look after a team or a region, and the people in those teams who do the day-to-day work. Access works best when it copies that shape instead of inventing a new one.
Three rules follow from it. Each manager looks after their own team, not everyone’s. Nobody manages a peer or anyone above them. And the person at the top can change everything, because someone has to be able to fix any mistake.
Within those limits, a manager adding someone to their own team shouldn’t have to ask the owner first.
Access by page, and by action
Next comes what “access” means. Handing out whole areas of the application is too blunt: the person who looks up a customer doesn’t necessarily need to delete one. A grid works better, with the application’s pages down one side and what you can do on them across the top:
- View: open the page and read it.
- Create: add something new, such as a customer or a statement.
- Edit: change what’s already there.
- Delete: remove it. Only a few people should.
- Export: download the list. This matters more than it looks, because an export leaves your application for good.
A manager can only give access they have themselves. If a manager loses access to something, their team loses it too, straight away, and nobody has to tidy up a dozen accounts. The team’s grants aren’t deleted, though. They’re kept on hold, so if the manager gets that access back, the team does as well.
Asking for more, and getting an answer
Rules like these fall apart if getting access means a chain of emails. When someone opens a page they can’t use, the application should tell them what the page is for and let them ask for it, with a reason.
The request goes to their manager, who can approve all of it or part of it, or decline, and add a note either way. If the manager doesn’t have that access either, they pass the request up a level instead of saying no. Everyone involved is told what happened at each step, inside the application, so nobody’s left wondering whether a request was seen.
A working example, and how it is built
We built a back office for a fictional facilities company, Varrowmere Facility Services, to show how this fits together. It has one super admin, twelve sub-admins who each run a region, and seventy-five admins between them, working across services, customers, statements and reports. A manager can view the application as someone in their team, which answers “why can’t they open this?” in seconds. An activity log records sign-ins, access changes and decisions. It’s built with Laravel, and a separate page explains how its access levels work.
For technical readers: a person’s effective access is what they were granted, limited to what their manager can do. It’s calculated when they use the application, not copied onto their account. The pages and actions are defined in one place, and every page checks them on the server, on every request. Hiding a button is a courtesy; the server refusing is the rule. Automated tests pin down the hierarchy, the grants and the request flow, so a change in one place can’t open a door somewhere else without a test failing.
When you do not need this
If five people run everything together and trust each other completely, individual logins and a record of who changed what may be all you need. Levels, grids and approvals earn their place when teams, regions or outside staff arrive, or when the wrong person changing the wrong thing would really cost you. If you’re still deciding whether you need an application of your own at all, start with when your business needs a custom web application.
Access rules are part of custom web application development, and they’re easiest to get right before anyone has logged in. You tell us what the application is for. We ask about your users, your business goal and your constraints, then recommend a scope and an approach, including how much of this you actually need. Describe what you are working with and we’ll reply by email.