ERPNext user permissions should let employees complete their assigned work while preventing access that is unnecessary or unsafe. Using an administrator account for daily operations may seem efficient during a demonstration, but it makes approvals, data ownership and audits harder to trust. A maintainable permission model begins with job functions and standard ERPNext controls rather than separate exceptions for every individual user.
Start with roles and responsibilities
Define job functions such as Sales User, Stock User, Accounts User and relevant approvers. Assign standard or organisation-specific roles based on what a person needs to do. Role Permissions Manager can define operations such as Read, Write, Create, Submit and Cancel for different DocTypes.
Avoid assigning broad permissions merely because a menu is not visible. Investigate the actual document-level access requirement and test with a representative account for each role.
Separate creation, approval and cancellation
The person who prepares a purchase, discount or accounting document may not be the appropriate person to authorise it. Where financial or operational risk requires separation, define a workflow that identifies the approver and records transitions.
Not every organisation needs the same approval depth. Low-risk routine operations may be automated, while exceptional price changes, stock adjustments or cancellations require controlled authority. The policy should match business impact.
Restrict the scope of data users can see
User Permissions can restrict access to linked records such as Company, Warehouse or other business dimensions where supported by the document model. This is distinct from hiding a navigation entry with front-end CSS: it is intended to control the records available to an authenticated user.
Test cross-company and cross-warehouse scenarios. An employee should not gain access simply by guessing a document URL or using an API that the interface does not normally expose.
Use workflows for clear accountability
Map the transition from draft through approval, submission and cancellation. Record who can move a document between states, which information must be present and what happens if an approver is absent. Avoid inventing unnecessary states that duplicate standard ERPNext lifecycle status.
Workflows must also handle revisions and rejection. Users should know whether a rejected document can be edited, who re-submits it and whether a new approval is required after material changes.
What an audit trail should demonstrate
An auditor or manager should be able to identify the document, the initiating user, approval decisions, timestamps and relevant changes. For critical operations, consider the relationship between ERPNext document versions, comments, workflow actions and system logs. Retention requirements depend on risk, privacy policy and applicable obligations.
Audit readiness is not the same as having an ISO badge or extra form fields. Evidence must show that controls operated in practice and that exceptions were reviewed.
Remember integrations and AI service accounts
API users and MCP-connected assistants need permissions that are at least as carefully scoped as human users. Separate read-only analytics access from actions that change business records. Use dedicated service accounts, secure credentials and idempotent commands.
Prevent a chatbot or workflow tool from bypassing ERPNext validation or submitting financial records under an unrestricted administrator identity. Sensitive actions may require explicit human approval and logging under the agreed company policy.
Test permissions before go-live
Create a role-by-document matrix and execute real scenarios with non-admin accounts: sales order creation, warehouse delivery, invoice posting, approval and cancellation. Test negative cases too, including access to another company and unauthorised API writes.
Review security and governance guidance, ERPNext customisation and AI MCP integration when access requirements extend beyond standard user workflows. Keep changes documented and test again after upgrades.
