# Role-Based Access Control (RBAC)

> Source: https://netray.co/glossary/role-based-access-control
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Glossary

## Short answer

Role-based access control grants ERP permissions to roles that match job functions, then assigns users to roles, instead of setting permissions user by user. It makes access consistent, reviewable and easier to remove.

## Aliases

- RBAC
- ERP roles and permissions
- user roles

## Category

erp-core

## Full Definition

In role-based access control (RBAC), permissions are attached to a role such as Buyer, Production Planner or AP Clerk, and users receive access by being assigned one or more roles. When a person changes job, you change their role, not dozens of individual settings. This is the default access model in nearly every mid-market and enterprise ERP.

Each system has its own vocabulary. NetSuite roles are collections of permissions with a level (View, Create, Edit, Full) per record type and can be restricted by subsidiary, department or location. Infor SyteLine groups users and grants rights on forms, IDOs and methods, with additional restrictions at the site level. Infor LN uses authorization by user type and session-level permissions. SAP uses roles built from authorization objects, bundled into composite roles.

RBAC fails in predictable ways. Roles are copied and tweaked until hundreds exist (role sprawl), a temporary elevated role is never removed, or an administrator role is shared by too many people. A healthy design has a small set of well-named job roles, a clear owner for each, and a regular recertification where managers confirm who still needs what.

Row-level restrictions matter as much as function-level ones. A buyer may need purchase order access only for their own site or commodity, and a plant manager should not see another subsidiary's costs. Where the ERP cannot express such a rule natively, it is often enforced in the integration or reporting layer.

## Why It Matters

- It reduces the work and error rate of onboarding, transfers and offboarding because access follows the role.
- It is the foundation for segregation of duties and for answering an auditor's question of who can do what.
- Poorly designed roles quietly grant cost, pricing or HR visibility to people who should not have it.
- Any AI assistant connected to the ERP should map to existing roles so its answers respect the same data boundaries as the user.

## In Practice

A manufacturer migrating to a new ERP finds 140 custom roles for 300 users. It consolidates them into about 25 job roles, each with an owner, and adds site restrictions for buyers and planners. Quarterly recertification then takes a manager under an hour per department instead of an ad hoc scramble before the annual audit.

## Faq

### What is the difference between a role and a permission?

**Answer:** A permission is a single right, such as editing purchase orders. A role is a named bundle of permissions for a job function, and users get access by being assigned roles.

### How many roles should an ERP have?

**Answer:** There is no fixed number, but a mid-sized manufacturer usually manages well with a few dozen job-based roles. Hundreds of near-duplicate roles is a sign of role sprawl.

### Does RBAC apply to AI agents connected to the ERP?

**Answer:** It should. An agent should run under a service account or the asking user's identity with a defined role, so it can never read or change more than that role allows.

## Search terms

role based access control ERP, ERP roles and permissions, RBAC in ERP, NetSuite roles, SyteLine security groups, ERP user access, role sprawl, least privilege ERP

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json