Plan permissions in B2B software with roles, companies, units, and access tests to protect data without making administration impractical.
Index
A different menu for each user does not prove isolation. The application needs to verify authorization on each relevant access, including exports and integrations. The design must start with the actions and boundaries of the business, avoiding excessive access and an unmanageable matrix.
Decision this guide helps you make: Define coherent authorization between interface, API and data.
Separate identity, bond and role
The same person can participate in more than one company with different responsibilities. The role must be interpreted in the correct context. Define how invitations, transfers and terminations change links. Don't just use the email domain as proof of authorization for all of an organization's data.
Model actions and objects
Read, edit, approve, and export may require different permissions. Some rules also depend on the state of the registry or unit. Document examples of allowed and denied access. The interface must reflect these decisions, but protection must exist in the service responsible for the operation.
Test beyond normal navigation
Check for changing identifiers, direct API calls, and using old links. Test users from different companies trying to access the same object. Include background tasks and stored files, which may escape screen checks. The review must produce reproducible evidence without exposing real data.
Make administration understandable
Managers need to know what a role allows and review access without guessing combinations. Avoid permanent privileges for convenience. Record changes and define administration recovery in anticipated situations. The proposal must cover the access life cycle, not just the registration screen.
- Explicit company and unit boundaries.
- Actions checked on the server.
- Negative testing and privilege review.
A scenario to check out in the demo
Hypothetical example: a manager of a unit can export a report that includes other units. The canvas appears restricted, but the export operation uses a different filter. The test needs to reach this path and check the generated content. The correction should be in the shared authorization rule whenever possible, reducing divergences between screens and APIs.
Briefing to request a proposal
- Product-relevant organizational roles and boundaries.
- Sensitive actions such as exporting, approving and managing users.
- Access denied scenarios that will be part of the acceptance.
Draw the matrix with the operation
Quantum9 can map roles and implement product-aligned controls. Take examples of users and tasks, without credentials. Acceptance must include denied attempts and administrative flows, in addition to demonstrating that the authorized user is able to work.
Discover the scope of Tailor-made development and deepen the context in related guide.