The right access for each person.
An admin and a customer obviously shouldn't see the same screens. The harder questions are finer than that, and they decide whether people trust the system with sensitive information.
Access is rarely just admin or user.
A few situations that show why roles need more thought than a dropdown.
One location, full detail
A manager in Pune sees every record for their branch, amounts included, but nothing from Chennai unless they're covering for that branch.
Only what's assigned
A partner sees the leads and orders assigned to them and the stock they may sell, the arrangement described on our partner portals page.
Money, not conversations
Finance needs invoices and payment status across all branches but has no reason to read sales notes.
Their own account only
A customer logs in to a customer portal and sees their requests and documents, never another customer's, even by editing a link.
Read-only, for a while
An auditor needs to review a year's transactions for a few weeks. They can look and export within that scope, change nothing, and lose access when the engagement ends.
Today's visits on a phone
A technician sees the jobs assigned to them for the day and can update their status, without access to pricing or the customer list as a whole.
Permission sits on what people do.
Hiding a button isn't enough. Each rule has to apply to the records and actions behind the screen, including exports and integrations.
Edge cases worth planning for.
Temporary access
Someone covers a colleague's region for two weeks. Access should come with an end date instead of staying on forever.
Role changes
A sales executive becomes a team lead. New rights apply at once, and rights from the old role that no longer fit are removed.
Staff departures
Access ends on the last day, open work is reassigned, and the person's past actions stay attributed to them.
Hierarchy
Managers may need their team's records. We can model your structure so visibility follows reporting lines.
A good place to start is one restricted action. Take exporting customer information. Should everyone be able to do it, only managers, or one named role? Can they export every record, or only the ones they can already see on screen? Should each export be logged with who ran it and what it contained?
Working through a single action like this surfaces the real rules faster than a list of job titles. It also catches the gap we see most often in older systems: screens that hide data correctly while the export or an integration hands out everything. Recording sensitive actions is covered on our audit trails page.
Common access questions.
Can managers see more than their own team?
Yes. We can build a hierarchy around your organisation structure, so a regional head sees every branch in the region while branch staff see their own.
Can permissions change without a new release?
For the settings we agree should be configurable, yes: authorised admins assign roles and adjust access inside the application. A new kind of boundary, such as splitting by product line, is development work.
Do integrations follow the same rules?
They should. Each connected system gets its own credentials with only the access it needs, and its actions are recorded like a person's. A reporting tool that only reads sales data has no business writing to it.
How does this work when several companies use one platform?
Each organisation gets its own users and roles inside a firm boundary. That design is covered under multi-tenant platforms.
Send us three people and what they should see.
Real examples from your team are the fastest way to agree the access model.