ERP Roles and Permissions: A Least-Privilege Design Guide
By Apex Horizon Digital
ERP access is often designed by copying an experienced employee's permissions or granting a broad role when someone cannot complete a task. That feels efficient until staff can create and approve the same transaction, view sensitive data outside their responsibility, or keep access after changing jobs. Least privilege means giving each identity only the access needed for authorized work. In an ERP, that requires more than menu visibility. The design must cover action, data scope, workflow state, monetary limit, sensitive fields, administration, and time.
Key takeaways
- Design roles from job tasks and prohibited combinations, not from individual user requests.
- Separate create, approve, fulfill, adjust, pay, and report capabilities where risk requires independent control.
- Test allowed and denied scenarios, review access regularly, and preserve evidence of every change.
1. Convert job responsibilities into permission statements
List recurring tasks for each job function and express access as a verb, object, scope, and condition. A statement such as approve purchase orders for Company A up to a defined limit is testable. A label such as procurement power user is not. Include view, create, edit, submit, approve, cancel, export, adjust, post, pay, configure, and administer actions. Record whether access applies to a company, branch, warehouse, department, project, or assigned customer set. Define sensitive data separately. A warehouse operator may fulfill an order without seeing margin, bank data, or payroll. Use job roles as reusable bundles, then document exceptional additions with an expiry date and owner.
- Verb and business object
- Data and organizational scope
- Condition, state, and limit
- Sensitive-field visibility
2. Build a separation-of-duties matrix
Map critical transaction chains from request to settlement. Mark steps that create an obligation, move an asset, change a balance, or conceal evidence. Combinations to challenge include creating a supplier and changing its bank account, requesting and approving a purchase, receiving and adjusting stock, creating and approving a credit note, or preparing and releasing payment. For a small team, perfect separation may be impractical. Document the exception and add a control such as independent daily review, a lower approval limit, notification to an owner, or restricted scope. The matrix should name the risk, prohibited combination, exception approver, and monitoring evidence.
- Create versus approve
- Fulfill versus adjust
- Prepare versus release payment
- Exception and compensating review
3. Add data scope, workflow state, and approval limits
A role can be safe for one warehouse and unsafe across the whole company. Combine functional permissions with row-level scope where supported. Limit actions by legal entity, business unit, location, project, or assignment. Define temporary cover arrangements and expire them automatically. Apply state and amount restrictions at the server or workflow layer, not only by hiding buttons. Users who create a draft should not bypass validation through an integration endpoint. Approval limits should use a defined currency and a rule for split transactions. Role assignment, configuration changes, audit-log administration, and bulk export need distinct approval because they extend impact beyond routine operations.
- Company and location scope
- Workflow-state restriction
- Amount and currency rule
- Administrative access boundary
4. Test permissions with positive and negative cases
Create representative test users for every role. Verify required tasks, then deliberately attempt actions that must fail. Test direct URLs, exports, APIs, mobile views, integration accounts, bulk actions, and records outside scope. Confirm that denial messages do not expose sensitive details. Test behavior after a record changes state or exceeds a limit. Maintain a role-permission matrix mapping each role to actions, scopes, and constraints, and link test evidence to the implemented configuration version. When permission changes, rerun affected scenarios. Negative testing is essential because an authorized flow that succeeds says nothing about an unauthorized path.
- Required task succeeds
- Forbidden action fails
- Out-of-scope data stays hidden
- API and bulk paths match the UI
5. Govern joiners, movers, leavers, and periodic review
Access requests should name the role, scope, business reason, approver, start date, and expiry for temporary access. Job changes must remove old permissions, not only add new ones. Disable departed users promptly and rotate integration credentials when ownership changes. Avoid shared accounts because they destroy individual accountability. Run periodic reviews using actual membership, activity, exceptions, and sensitive capabilities. Managers confirm job need while system owners verify technical meaning. Remove unused access and investigate dormant privileged accounts. Keep an audit trail of requests, approvals, changes, tests, and review decisions. The durable artifact separates create, approve, fulfill, adjust, report, pay, export, and administer actions.
- Request and approval evidence
- Mover access replacement
- Leaver and credential control
- Periodic certification and removal