User Roles and Permissions Guide

User roles and permissions are the mechanism that decides who can see what and do what inside a business system. In a CRM, a customer portal, an admin panel or a document workflow, not every user should have the same access. Roles and permissions are how you enforce that distinction in software.

The two concepts are related but distinct. A role is a named collection of permissions assigned to a type of user — for example, "Sales Manager" or "Support Agent". A permission is a single specific right, such as "view client records", "edit invoices" or "export reports". When you assign a role to a user, they inherit all the permissions bundled into that role.

This sits alongside authentication, which confirms identity (logging in with a username and password, or through single sign-on). Authentication answers "who are you?". Authorisation — which is what roles and permissions provide — answers "what are you allowed to do?". Both are necessary, but they solve different problems.

Define access around these controls

Why IT matters for business systems

In a spreadsheet-based operation, access control often amounts to sharing a file with certain people or not. Once you move to a web application, the system needs rules built into it, because every user logs into the same interface. Without defined roles, you face a binary choice: give everyone full access or build a separate application for each group. Neither is practical.

Roles and permissions also affect compliance. If your system handles personal data, you need to demonstrate that access is limited to those who need it for their job. A well-structured role model provides evidence of that control. If an auditor or a data-protection review asks who can download client records, the answer should come from the system's permission structure, not from an informal understanding among staff.

Levels of access

Permissions operate at different levels of granularity. The broadest level is feature access: can a user reach the reporting module at all? Below that is action access: within the reporting module, can they create a new report or only view existing ones? Then there is record-level access: can they see all client records, or only those assigned to their team? And finally field-level access: within a client record, can they see the financial details or just the contact information?

Not every system needs all four levels. A simple internal tool might only distinguish between feature and action access. A CRM handling sensitive commercial data might need all four. The right level depends on what the system does and what the business risk is if the wrong person sees or changes something.

CRM systems

In a CRM, roles typically reflect the sales structure. A sales representative might create and edit their own leads, view (but not edit) shared accounts, and generate their own reports. A regional manager might edit any record within their region and view reports across their team. A finance user might have no access to the pipeline at all but full access to invoicing and payment records. An administrator can configure the system but may be restricted from altering live financial data without a secondary approval.

The key practical question in a CRM is whether data access follows the user (they see everything they created) or the territory (they see everything in their region or assigned accounts). This distinction changes how permissions need to be structured and whether the system needs record-level rules in addition to role-based ones.

Customer portals

Portals introduce a different dynamic because the users are outside your organisation. A client logging into a portal should only see their own documents, orders or project files. This is not typically handled through roles in the traditional sense — every external user has the same role — but through data isolation. The permission model needs to ensure that the system filters data by the authenticated user's identity, not just by their role.

Where roles do matter in portals is when you have different types of external users. A primary contact might approve invoices, a secondary contact might only view documents, and an auditor from the client's side might have read-only access to a specific subset of records. Each of these needs a distinct role with carefully limited permissions.

Document workflows

Document management systems often need permissions that change based on the state of a record. A drafter can edit a document while it is in draft status. Once submitted, they lose edit rights and a reviewer gains them. On approval, neither can edit, and a publisher can release the document. This means permissions are not static — they depend on the workflow stage as well as the user's role.

If your system has workflows like this, the permission model needs to account for state transitions. A simple role table that never changes will not be sufficient. The question to resolve early is whether the system needs dynamic permissions (where rights shift as a process moves forward) or whether static roles are enough because status changes are handled by reassigning the record to a different user with a different role.

Admin panels

Admin panels are often the weakest point in a permission model because they are built for internal use and sometimes treated as a single-access area. In practice, an operations manager configuring workflows, a finance officer running reports and a developer troubleshooting errors all need admin-level access, but to different parts of the system.

A practical approach is to split the admin panel into functional areas — user management, system configuration, reporting, data exports — and assign permissions for each area separately. This prevents a situation where someone who needs to pull a report also has the ability to delete user accounts or change system settings.

Temporary and changing access

People join teams, go on secondment, cover for colleagues and leave. A permission model that only works for a static organisational chart will become fragile quickly. Consider whether the system needs to support time-limited roles (access that expires on a set date), delegated access (a manager temporarily taking on a team member's permissions), or role history (a record of who had what access and when). These features add complexity but reduce the risk of stale permissions accumulating over time.

Access-control mistakes and checks

Over-permissioning by default

The most frequent mistake is giving users more access than they need, usually to avoid friction during setup. A new hire is given the "admin" role because it is the quickest way to get them working. Over time, the organisation accumulates a large number of admin-level users, many of whom no longer need that access. This increases the risk surface and makes it harder to trace who changed what.

The practical check is simple: can you produce, from within the system, a list of who currently holds each role? If that takes manual effort or is not possible, the permission model is not being managed actively.

Role explosion

The opposite problem is creating a separate role for every slight variation in access. If you have roles like "Sales Manager — North", "Sales Manager — South" and "Sales Manager — North (Read-Only)", the model becomes difficult to maintain. When a new region is added or a permission changes, you have to update multiple similar roles and risk inconsistencies.

The usual solution is to separate the concerns: use roles for functional permissions (what actions a sales manager can perform) and a different mechanism — such as team assignment or territory rules — for data scoping (which records they can perform those actions on). This keeps the role list short and the data-filtering logic separate.

Hardcoded permissions

Some systems have permissions built directly into the application code rather than stored in a database or configuration layer. This means that changing a permission requires a code change, testing and deployment. For a system that will evolve, this is a significant limitation. When evaluating a system or briefing a supplier, ask whether permissions are data-driven (configurable by an administrator without code changes) or code-driven. Data-driven permissions are almost always preferable for business systems that will need to adapt.

Ignoring the offboarding path

Permission models are usually designed with onboarding in mind — what access does a new user need? The offboarding path is often neglected. When someone leaves, what happens to records they created? Do their approvals in workflows need to be reassigned? Can their account be deactivated without breaking audit trails? These questions should be considered when the permission model is first designed, not when a departure is already underway.

Permissions and integrations

If your system connects to other software through APIs or integrations, those connections often use their own credentials. An integration that syncs data to an accounting package, for example, might have broad read access to the CRM. The permission model should account for service accounts and API keys as distinct from human users, with their own restricted roles. Treating an integration as if it were a regular user with a full-access role is a common gap.

Limitations of role-based models

Role-based access control works well when access patterns are predictable and groupable. It becomes strained when access needs are highly individual — for example, a consultant who needs access to three specific client records and nothing else. Some systems handle this through attribute-based access control (where permissions depend on properties of the user, the data and the context) or through explicit record-level grants. For most business systems, roles combined with data scoping are sufficient, but it is worth recognising the boundary where a purely role-based model starts to require workarounds.

Key checks before committing to a design

• Can you list every role the system will need, and is the list short enough to maintain?
• Does each role map to a real job function, not a convenience grouping?
• Are permissions configurable without code changes?
• Does the model handle record-level and field-level access where the business requires it?
• Is there a clear process for granting, reviewing and revoking access?
• Do integrations and service accounts have their own restricted roles?
• Can the system report on who holds which role at any given time?
• Does the model account for temporary access, delegation and offboarding?

Answering these questions does not produce a final permission design — that is the subject of detailed planning. But it establishes whether the system you are building or buying can support the access control your operation actually needs, and where the gaps are likely to appear.