Articles

Defining user roles for a multi-tenant application

A multi-tenant application serves multiple organisations from one product, while each customer expects its data, settings and workflows to remain separate. Clear role definitions are the foundation for that separation. They determine who can view records, invite colleagues, change configuration, approve work and access sensitive information.

Role design should begin with real user behaviour rather than a list of technical permissions. A small business in Perth may need a simple owner-and-staff model, while a national organisation with teams in Sydney, Melbourne and regional areas may require layered administration, delegated access and detailed audit records.

Start with tenants and responsibilities

First define what a tenant represents. It might be a company, school, government department, franchise, project team or business unit. Some customers may have several brands or locations inside one tenant, so the model should distinguish the customer account from its internal workspaces.

Then describe the responsibilities associated with each person. An account owner may control billing and contractual settings, whereas a tenant administrator manages members and policies. A project manager might control one programme without seeing every project owned by the organisation.

Use a UCD workflow to document these assumptions before implementation. UCDmanager can help teams organise user research, requirements, usability activities and design decisions in one collaborative project.

Separate global and tenant-level access

Multi-tenant systems commonly have two permission layers. Platform-level roles belong to the service provider and may support operations, security or customer support. Tenant-level roles belong to the customer and should be limited to that organisation’s data and configuration.

Avoid giving support staff unrestricted visibility by default. A support role may need temporary, recorded access to diagnose an issue, but that access should be scoped, time-limited and visible in an audit trail. Australian customers often expect practical transparency around privacy, especially when information is hosted or supported across state or national boundaries.

Common role boundaries include:

Map roles to tasks and use cases

Permissions become easier to evaluate when linked to tasks rather than job titles. “Marketing manager” can mean different things across organisations, while “can publish a campaign” is a testable capability. Write use cases for ordinary work, exceptional events and account administration.

For example, a staff member may create a record, a reviewer may approve it, and an administrator may archive it. A user could hold several capabilities without receiving broad access to unrelated functions. This approach also exposes missing roles, such as a read-only auditor or an external collaborator.

A library of use case examples can help teams express actor goals, system responses and alternative paths. Include scenarios such as a contractor joining one workspace, a manager approving access, and an employee leaving the organisation.

Build a permission matrix

Create a matrix that crosses roles with resources and actions. Resources might include customer records, reports, billing details, integrations and audit logs. Actions can include viewing, creating, editing, deleting, exporting, approving and managing access.

Do not rely on a single “admin” switch. A regional coordinator may edit users in Queensland but not alter national security policies. A finance officer may view invoices without accessing user research or support notes. These distinctions reduce accidental exposure and make role reviews more straightforward.

Useful permission questions include:

Validate roles with personas and edge cases

Personas bring context to an access model. Describe a tenant owner, occasional contributor, external consultant, compliance reviewer and platform operator, including their goals, technical confidence and working environment. A regional user may rely on a mobile connection, while a head-office administrator may use complex desktop workflows.

Effective user persona guidance helps prevent a role matrix from becoming an abstract spreadsheet. Test each persona against realistic journeys: joining an account, requesting access, recovering an account, sharing a report and handing over responsibilities.

Also test edge cases before development is complete. Consider a person belonging to two tenants, an employee with two jobs, an administrator who loses access to their email, and a contractor whose engagement ends on a Friday afternoon. These situations often reveal unsafe inheritance rules.

Account for Australian expectations

Australian applications need a clear approach to privacy, consent and record handling. Consider the Privacy Act and Australian Privacy Principles where they apply, along with contractual commitments made to customers. Retention, deletion, access requests and breach response should be reflected in both permissions and operational procedures.

Local context also affects design. A national retailer may need separate store-level access from its Melbourne head office, while a community service may coordinate workers across remote Western Australia with intermittent connectivity. Use plain Australian English in labels and notifications, and make approval steps understandable to someone trying to finish a task before the arvo.

Regulated workflows deserve especially careful modelling. For example, a gambling-related tenant may separate customer support, marketing and safer-gambling oversight, with restricted visibility for sensitive interactions. A responsible play pledge can illustrate how policy commitments translate into review, escalation and accountability requirements.

Govern roles after launch

Role design is not a one-off configuration exercise. Review permissions when new features, integrations, business units or regulations are introduced. Monitor unusual access patterns, failed authorisation attempts and dormant accounts, while avoiding surveillance that is unrelated to a legitimate security purpose.

Give tenant administrators understandable tools for inviting users, assigning roles and reviewing access. Provide explanations when an action is blocked, and let people request additional access through a controlled workflow. This is more useful than displaying a generic “forbidden” message.

Maintain versioned documentation for every role, permission and exception. Run usability testing with both administrators and everyday users, then compare observed behaviour with the intended security model. A well-defined role system should protect tenant boundaries while allowing people to get their work done without unnecessary permission tickets.