Permission
A permission is the authorization assigned to a user, role or group to perform a specific action in the ERP system – such as viewing, creating, editing or deleting data.
A permission is the authorization assigned to a user, role or group to perform a specific action on a specific object in the ERP system. It defines who may view (read), create, modify (update) or remove (delete) which data, and which modules, tenants or records the access even extends to. Without a permission, a function stays invisible or blocked for the user.
Permissions are the foundation of access control. In an ERP system that unites financial accounting, warehouse, purchasing, sales and personnel data under one roof, the permission decides that the warehouse worker posts stock but cannot open payroll lists, and that the accountant approves invoices without being able to overwrite item master data. It protects sensitive information, prevents errors and is a prerequisite for audit-proof, GDPR-compliant processes.
At a glance
- Permission = authorization for a concrete action (read, create, update, delete) on an object
- Almost always bundled through roles instead of granted individually per user
- Implements the principle of least privilege
- Basis for GDPR compliance, audit readiness and segregation of duties
- In multi-tenant systems additionally scoped per tenant
How a permission is structured
At its core, a permission links three elements: a subject (who?), an object (on what?) and an operation (what may be done?). The subject is the user or – more often – the role they are assigned to. The object can be an entire module ("financial accounting"), a single record type ("customer master") or even a field. The operation usually follows the CRUD scheme: Create, Read, Update, Delete, supplemented by special rights such as approving, exporting or printing.
Modern ERP systems additionally distinguish functional and data-related permissions. A functional permission allows calling a function at all (e.g. "create purchase order"). A data-related permission narrows down which records that function acts on – for example only documents of a certain cost center, location or tenant. Only the interplay of both produces effective, precise access control.
Allow and deny rights
Permissions are modeled either as allow rules (something is permitted, everything else forbidden) or as deny rules (something is explicitly forbidden). The proven principle is "everything is forbidden that is not explicitly permitted" (whitelist). Explicit denies only make sense when they deliberately restrict a broader permission. Too many overlapping rules quickly make a rights concept confusing and error-prone.
Permission, role and right: the distinction
In everyday usage "permission", "right" and "role" are often used interchangeably, yet they mean different things. A right (or privilege) is the smallest unit – the atomic authorization for a single operation. A permission is the concrete assignment of such a right to a subject. A role is a named bundle of many rights that corresponds to a job, such as "purchasing clerk" or "controller".
Instead of assigning dozens of individual rights to each employee, you assign them to one or more roles – this is the principle of role-based access control (RBAC). The benefit: if a task changes, you adjust the role once and all holders inherit the change. New employees are simply assigned the matching role during onboarding. This drastically reduces maintenance effort and sources of error compared with granting rights per person.
Why permissions matter in the ERP
An ERP bundles a company's business-critical data. A clean permission structure serves several purposes here at once. It implements the principle of least privilege: everyone receives only as much access as their task strictly requires. This limits the damage from compromised accounts and prevents accidental changes to other people's data.
Equally important is segregation of duties: whoever creates a purchase order should not be allowed to approve and pay it themselves. Permissions enforce this control technically and are therefore a central element of internal control systems and fraud prevention. For data protection under the GDPR, restricted access to personal data is even legally required – only authorized persons may view customer or personnel data.
Finally, permissions support audit readiness. Combined with a log (audit log), it can be traced who was allowed to perform which action, when, and actually did. In tax audits and within the scope of GoBD, this traceability is a tangible argument.
Permission models: RBAC and ABAC
The model dominating ERP systems is role-based access control (RBAC). Rights are bundled into roles, roles are assigned to users. The model is clear, easy to audit and completely sufficient for most mid-market scenarios.
Where finer control is needed, attribute-based access control (ABAC) comes into play. Here, attributes of the user, the object and the context decide on access – such as department, location, document value or time of day. An example: approvals over 10,000 euros only by the "division manager" role. Many ERP systems mix both approaches: roles as the framework, supplemented by data-related filters and value limits.
Permissions and tenants
In multi-tenant ERP systems another dimension is added: permissions can be granted separately per tenant. A user can have full access for tenant A and none at all for tenant B. This lets several legally separate companies or brands be cleanly isolated from one another within a single installation, without having to operate separate systems.
Maintaining permissions properly
A permission concept is not a one-off project but an ongoing operational task. Roles and rights should be reviewed regularly (recertification) so that former responsibilities do not persist as "rights debt". Especially when employees leave or change departments, the timely revocation of no longer needed rights is decisive.
In practice, a few clearly cut standard roles instead of many special cases, a documented role-rights matrix and coupling to a central identity via single sign-on have proven effective. When user management is controlled through a central directory, blocks take effect immediately system-wide – an important building block for security and compliance.
Example
Example: rights in a trading business
A trading company with 40 employees introduces its ERP with four core roles. The "warehouse" role may post goods receipts and goods issues and view stock, but has no access whatsoever to financial accounting. The "purchasing" role creates purchase orders, but from a value of 5,000 euros may no longer approve them itself – that is handled by the "purchasing management" role.
The accountant sees open items and posts payments, but can only read item master data. This ensures that no one alone can run through a complete procurement and payment process from order to disbursement. If an employee is absent, IT simply assigns their stand-in the matching role – without having to manually recreate dozens of individual rights.
Frequently asked questions
Related services
Sources
Questions about Permission in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.