A customer invites an accounts colleague to download invoices. That person should not automatically gain permission to delete projects, export every customer record or change the subscription owner. As a business app grows beyond a single user, access needs to follow the tasks people perform.
For Irish SaaS teams, a permissions plan makes scope clearer before screens and integrations multiply. This guide focuses on what a signed-in person can do. Our passkeys and account recovery guide covers proving who the person is; permissions answer a different question once they are signed in.
Start with actions and records
List the business objects in your product, such as customers, jobs, invoices and reports. For each, identify the actions people need: view, create, edit, approve, export and delete. Include bulk operations and background processes, which are easy to overlook when reviewing only visible screens.
Then describe the scope of each action. A technician might edit assigned jobs while a manager sees jobs across one branch. An accounts user may view invoice totals without accessing private notes. These distinctions are more useful than beginning with an administrator checkbox and trying to repair its meaning later.
Build a small, understandable role matrix
Create a matrix with roles down one side and actions across the top. Give each role a name customers recognise. A first release might need owner, manager, team member and billing contact, but those are examples rather than a standard set every app should copy.
Ask a customer to explain the roles in their own words. If two roles sound identical but behave differently in important ways, change the names or simplify the model. Keep separate decisions for who can invite people, change permissions and transfer ownership. Those actions can have wider consequences than editing an ordinary record.
Enforce access on the server
Hiding a button helps the interface communicate a restriction, but the server still needs to enforce it. OWASP's authorisation guidance recommends least privilege, denying access by default and checking permissions on every request. Use those principles as part of the implementation and review process.
For a multi-company product, establish the organisation context on the server and check that each requested record belongs to the permitted organisation. Do not trust a company identifier supplied by the browser on its own. Apply the same boundary to exports, search results, attachments and asynchronous jobs, rather than protecting only the main detail page.
Design invitations and membership changes
An invitation should make the organisation and proposed access clear to the recipient. Decide who may send it, how long it remains valid and how an authorised person can revoke it. Avoid automatically adding someone to unrelated organisations because the same email address already exists in your system.
Plan what happens when a member leaves. Revoke their relevant access, review active sessions and tokens, and reassign work that still needs an owner. Keep a route for transferring the only owner role so an organisation is not stranded. Our SaaS onboarding UX guide covers the first-use experience around these account setup steps.
Separate approval from ordinary editing
Some actions need an additional business rule. A team member may prepare a refund request while a manager approves it. Record the status transition and authorised actor explicitly, rather than giving everyone a generic update permission and relying on the interface to prevent misuse.
Decide whether changing a submitted request invalidates an earlier approval. Make the amount, record version and final outcome visible to the approver. For subscription features, distinguish the person allowed to change a plan from the payment event that determines whether access is active. Our subscription billing article explains that lifecycle separately.
Give support controlled access
Support teams need enough context to diagnose a problem, but broad permanent access to every customer account creates unnecessary exposure. Define the support workflow, the permitted scope and the audit record. Where temporary access is appropriate, make its start, expiry and purpose explicit.
Log meaningful access changes, exports and administrative actions without copying sensitive record contents into logs by default. An audit trail should help explain who changed a role and when. It should not become another unrestricted copy of customer information. Agree who can inspect the trail and how long it is retained.
Test the boundaries, then explain them clearly
Test each role against allowed and blocked actions, including direct requests that bypass hidden controls. Use two test organisations and attempt to access records across their boundary. Check exports, revoked invitations, removed members and an ordinary user trying to grant themselves a stronger role.
Give customers a clear explanation when an action is unavailable and a route to contact their organisation's administrator. A well-designed restriction should not look like a broken page. Elephantfly builds business web applications around real operational roles. Discuss your permissions model with a few examples of who needs to access which records and why.
Further exploration
Sources & references
- 01
