ERPNext role permissions design

ERPNext role permissions design: who can do what before go-live

A rollout that covers accounting, stock, sales and production will have users who need very different rights, and the fastest way to get them working is often to hand out broad roles and fix problems later. That shortcut tends to leave people able to post journals, change prices or submit stock movements they have no business touching, and it is hard to unwind once users have built habits around it. Before go-live, decide which job functions exist, what each one must do in the system, and what it must never be able to do. ERPNext gives you the building blocks for this: a Role is a named set of permissions on DocTypes, and a Role Profile bundles several roles so you can assign a whole job function to a user in one step, as described in the ERPNext Role and Role Profile documentation.

A designed role model is needed as soon as more than one department shares the site, when segregation of duties matters for financial controls, or when new joiners need to be onboarded without an administrator editing permissions each time. Start with a matrix of job functions against DocTypes and actions (read, write, create, submit, cancel, and report access), then map each cell to the smallest role that covers it. Pay particular attention to submit and cancel rights on transactional documents, because those rights control whether a posted invoice or stock entry can be reversed. Confirm with your own testing, not assumptions, how each standard role in your ERPNext version behaves, and keep the System Manager role limited to the few people who truly administer the site. Your role matrix will feed directly into the field-level, user permission and login controls covered in the sibling sections.

Which role model fits your organization

Start from the roles ERPNext creates with the application and assign them without changing the role set. This keeps the rollout small and means the permission matrix matches what the community documents and what most implementers expect. It fits a single-company deployment with a small team, where a handful of people do every task and few users need to be separated from each other.

Low upfront design: no custom role catalog to agree on before go-live.
Recurring cost is low at first: changes are rare because there is little to change.
Break point: shipped roles are broad, so accountants, buyers and sales staff often end up with rights they should not hold once headcount grows.
Audit friction: reviewers have to trace each permission back to a generic role rather than to a job function.
Growth risk: adding segregation of duties later means reworking documents and users at the same time.

Before you commit, list the shipped roles your users would receive and ask a finance lead which of them would fail a segregation-of-duties review.

Role Permissions Manager, role profiles and custom roles compared

This table compares the four ways ERPNext grants access: the Role Permissions Manager, role profiles, custom roles and the System Manager role. Read each row as a configuration choice, asking what it is for, who should maintain it, how hard it is to audit and where it usually goes wrong.

Dimension	Role Permissions Manager	Role profiles	Custom roles	System Manager assignment
Purpose	Sets which roles can read, write, create, submit, cancel or export each DocType and perm level	Bundles several roles so one profile can be assigned to a user in a single step	Groups permissions for a job function that standard roles do not cover	Grants full administrative control over the site, including settings and customizations
Who maintains it	Functional administrator or ERP lead, with review by the finance or operations owner	ERP administrator, updated when a job function's role set changes	ERP administrator with a documented owner for each custom role	Only the smallest group of trusted platform administrators
Audit effort	Moderate: each DocType and role row needs review, so keep a written permission matrix	Low: check which roles each profile contains and who holds it	Moderate: confirm every custom role has a purpose and a named owner	High to verify: System Manager reaches almost everything, so the audit scope is the whole site
Typical risk	Rows added during testing remain in production, or a role gains submit or cancel rights it does not need	A profile grows over time as roles are added, so users accumulate access	Duplicate or overlapping roles that nobody remembers creating	Sprawl: more users receive System Manager for convenience, which bypasses most other controls
Change control	Export and review permission changes before they reach production	Review profile contents at each role change request	Track creation in the change log with a stated purpose	Restrict to a short, reviewed list and revalidate it on a schedule
Typical ERPNext use	Limit Sales Invoice submit rights to billing staff while sales users can only save drafts	Assign a Warehouse Clerk profile that includes stock and delivery roles	Create a role for an external auditor with read-only access to ledgers	Hold by one or two administrators, with a separate break-glass account

Submit and cancel rights that protect posted financial data

In ERPNext, creating, submitting and cancelling are separate permissions, and each one changes what can happen to posted accounting and stock records. The cards below cover how to split those rights, why cancel needs the tightest control, and how to decide who approves a transaction and who posts it.

Separate create from submit

A user with create rights can draft a Sales Invoice or Purchase Invoice, but a draft does not affect the ledger. Submit is the step that posts it. Grant create broadly to people who prepare documents, and grant submit only to the people accountable for posting. Check each transactional DocType in Role Permissions Manager, because the rows for create, submit and cancel are set independently. Confirm that no role holds submit by accident through a copied permission row.

Restrict cancel to a small group

Cancelling a submitted document reverses its effect on the ledger and stock, and it can leave a trail that auditors will question. Limit cancel rights to a named controller or finance lead, not to every submitter. Ask who will reverse an entry after period close, and whether that person needs a documented reason before they cancel. Test cancel with a non-admin user before go-live.

Split approval from posting

Where your control design requires it, one person should prepare an entry, a second should review it, and a third with submit rights should post it. ERPNext does not force this sequence by default, so the split depends on which roles hold which rights. Map each approval step to a role, then confirm that no single role can create, approve and submit the same document type.

Protect stock postings

Delivery Notes, Purchase Receipts and Stock Entries change inventory valuation as soon as they are submitted. Cancel and amend rights on these DocTypes should follow the same logic as accounting documents, with warehouse managers able to submit within their own warehouses where that restriction is configured. Ask your stock lead which corrections happen in practice, such as reposting or returns, and make sure those paths use a reviewed route rather than a cancel.

Use amend in place of silent edits

A submitted document cannot be edited directly. Amend creates a new draft linked to the original, which keeps the history visible. Decide whether your users may amend, and whether amendment rights need the same restriction as cancel. Review the amended-from links in your sample period close to confirm that corrections leave a readable trail.

Test the rights before users do

Build a test matrix with one user per role profile, then run create, submit, cancel and amend on a sample of invoices, payments, receipts and stock entries. Record which actions succeed and which fail, and compare the results with your written control design. Repeat the test after each role change, because a single permission edit can open cancel rights for a whole group.

How to design and roll out ERPNext roles in sequence

This sequence moves ERPNext role design from job functions to tested, assigned role profiles, so each user gets the access their work needs and nothing more. Each step ends with a check that the team can review before moving on.

Map job functions to DocTypes and actions
Start by listing each job function in scope, such as sales order entry, purchase approval, stock reconciliation, bank reconciliation and period close. For each function, record the DocTypes it touches and the actions it needs: read, create, write, submit, cancel and delete. Finance, operations and IT leads should sign off the matrix together, because accounting and stock rights often overlap. Done means every function has a row in the matrix and every row names an owner who approves it.
Draft roles from the matrix
Group the matrix rows into roles that describe what work a person does, not who they are. Keep System Manager out of the draft except for named platform administrators, and check whether a standard ERPNext role already covers each group before creating a custom one. Record the purpose of every role in a shared document. Done means each role has a stated purpose, an owner and a list of DocTypes it grants, and the list has been reviewed against the matrix.
Configure the Role Permissions Manager
Apply the drafted rights in the Role Permissions Manager, DocType by DocType, setting read, write, create, submit, cancel, amend and delete per role and permission level. Review each DocType for submit and cancel rights separately, since a role that can submit an invoice may not need to cancel it. Export the configuration or record the changes so the build can be repeated in a test site. Done means the configuration matches the draft roles and a second reviewer has checked the submit and cancel columns.
Build role profiles for each job function
Create a Role Profile for each job function, bundling the roles a typical holder needs. Keep profiles narrow and avoid bundling roles for unrelated work, because a profile that grows over time becomes the new source of over-access. Confirm the profile list against the matrix so every job function maps to exactly one profile or a documented combination. Done means each profile has a short description and the list of roles it contains has been reviewed by the business owner.
Assign users and review effective roles
Assign one Role Profile to each user, then open a sample of user records and confirm the roles and any direct role assignments match the intended job. Look for leftover roles from earlier setups and for users who hold System Manager without a documented reason. Ask the IT team to record the assignment rule so new starters follow the same path. Done means a sample of users, including at least one from each profile, shows only the roles their profile grants.
Test each profile with representative accounts
Create test accounts for each profile on a non-production site, then sign in as each one and attempt the tasks in the matrix, including the ones that should fail. Record what each account can see, create, submit and cancel, and compare the results with the expected behaviour. Verify that masked or restricted fields and document-level restrictions still apply, since role permissions alone may not cover them. Done means every test case has a recorded pass or a documented fix, and the business owner signs off the results.
Review roles after go-live
Schedule a permissions review after go-live and repeat it whenever a new module, custom DocType or app is added. Compare the current role assignments with the matrix, remove stale roles, and check the System Manager list against the named administrator register. Track changes to roles and profiles in a change log so audits can trace who approved each change. Done means the first review has been completed, its findings are closed or assigned, and the review cadence is recorded in the operations runbook.

Avoiding System Manager sprawl in ERPNext

System Manager is the broadest role in ERPNext, and it quietly overrides the permission design built for every other role. The cards below cover why it spreads, how to stop it, and how to keep a small, accountable administrator group in place after go-live.

Why System Manager removes protection

Holders of System Manager can edit almost any DocType, change Role Permissions, alter customizations and manage users. Any role-level restriction you design for accountants, buyers or warehouse staff stops mattering for anyone who holds this role. Before go-live, list every user with System Manager and confirm each one needs it for a documented administrative task, not for convenience.

Promotion as a quick fix

The most common cause of sprawl is a user blocked from a single action, such as submitting a journal entry or opening a report, who is promoted to System Manager to unblock them. The fix is usually a missing permission on one DocType or one role, so trace the exact missing right first. Log each access request with the DocType, the action and the role that should have covered it.

Named administrator group

Limit System Manager to a short, named list of people who run configuration, user administration and upgrades. Record the owner of each account, the reason it was granted and the date of the last review. Ask your implementation partner and internal team to agree on who approves additions before the first administrator account is created.

Separate break-glass account

Keep one tightly controlled emergency administrator account separate from daily administrator work, with its credentials held by a defined custodian and its use logged. This protects you from a lockout without leaving standing admin rights on everyday accounts. Confirm how this account is stored, who can reach it and how its use is reviewed.

Use role profiles instead of admin roles

Give job-function access through Role Profiles that bundle the standard roles a finance clerk, buyer or sales lead needs, so administrative roles never become a shortcut. When a function needs a new capability, add it to the role profile and test it with a sample user. This keeps the permission model readable as headcount and entities grow.

Review administrator changes regularly

Administrator sprawl returns slowly unless someone checks it. Schedule a recurring review of users holding System Manager, of roles added to them, and of Role Permissions Manager changes. Ask your team to confirm how this review is recorded so an auditor or internal control reviewer can later see who approved each change.

Questions teams ask before designing ERPNext roles

How much effort does an ERPNext role design take?

The effort depends mostly on how many distinct job functions the business has, how many companies or branches share the site, and how many custom DocTypes need their own permission rows. A single-company site with a handful of functions is a much smaller exercise than a group with several legal entities, shared service teams and custom approval steps. Each job function needs a list of DocTypes, the actions allowed on each (read, write, create, submit, cancel, delete) and the reasons behind them. Ask any partner to show how they count these items before they give a number, and ask what changes if the role count doubles.

Can our internal staff design ERPNext roles without a partner?

Yes, if someone on the team understands both the ERPNext DocTypes and the accounting or stock processes they control. Standard roles and the Role Permissions Manager are available to any user with the right access, and the Role and Role Profile documentation explains how a profile bundles roles for assignment. The harder part is the segregation of duties review, which needs finance, operations and audit input that engineers rarely hold alone. Many teams use an internal lead for the design and bring in outside help for review, testing and documentation.

What does the business need to provide for role design?

The design needs named process owners for sales, purchasing, stock, accounting, production and HR, because each owner decides who may create, submit and cancel documents in their area. The business also needs to sign off the segregation of duties matrix, including which combinations of rights no single person should hold, such as creating a supplier and approving its payment. Expect the owners to review draft role matrices more than once. Without these decisions, the technical work stalls or gets reversed after go-live.

How long does it take to test ERPNext roles?

Testing takes as long as it takes to walk each role through its real daily tasks on a staging site with representative data. Plan test cases for each role's allowed actions, each blocked action, field-level visibility and the submit and cancel paths for key documents. Retest after every change to a role, and again after upgrades, because permission behavior can shift between releases. Ask a partner for the test cases and the number of test rounds they include in the written scope, rather than a single sign-off date.

Which submit and cancel rights create the most risk?

Rights to submit and cancel financial documents such as sales invoices, payment entries and journal entries carry the most risk, because they change ledgers and stock. Cancellation of a submitted document reverses its effects, so the cancel right should sit with a narrow group, often separate from the people who create the documents. Review also which roles can edit submitted documents through amendment. Document the reason for each right so auditors and future administrators can follow the logic.

What should a partner quote for ERPNext role design include?

A written quote should list the job functions in scope, the DocTypes and companies covered, the custom DocTypes or fields that need permission rows, and the deliverables, such as the role matrix, role profiles, the segregation of duties review and test scripts. It should name what the client provides, including process owners and test users, and state how many review and test rounds are included. Ask whether post-go-live changes and future upgrade reviews are priced separately or covered by a retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.

Does a role design also need to cover system administrator access?

Yes. The System Manager role grants broad control over the site, so each administrator should hold it only when the job requires it. Keep the number of accounts with that role small, document who holds it and review the list on a fixed schedule. Keeping day-to-day users out of administrative rights prevents accidental changes to permissions, customizations and settings, which is one of the most common causes of wider access than intended. Confirm the current behavior of the System Manager role in the release you run before finalizing the design.

How DeployOpen scopes and delivers ERPNext role design

DeployOpen starts every ERPNext role engagement by agreeing the role model in writing before any configuration begins. The written scope lists the job functions in your organization, the DocTypes each function must read, create, submit, cancel or amend, the roles that map to them, and the users who will hold each role profile. It also records which accounts stay outside the role model, such as the Administrator account and any break-glass account, and who on your side approves changes. Because engagements are fixed-scope, the deliverables and the review points are fixed in that same document, so the reader knows what is handed over and when.

Delivery follows that agreement. DeployOpen builds the Role Profile records that bundle roles for each function, applies the permissions that the scope specifies, and creates test accounts that hold one role profile each, so your reviewers can log in as a finance clerk, a warehouse operator or a sales manager and confirm what they see and what they can submit. The permission matrix is exported and documented in a form your internal audit or external auditors can follow, showing each role, DocType, permission level and right. DeployOpen prepares this evidence and does not issue audit opinions. Ask the team how the matrix will be versioned, since each later change to a role needs its own record.

After go-live, role drift is the usual problem: new hires get System Manager as a shortcut, and submit rights are granted to fix one urgent report. DeployOpen can support periodic reviews of the live permission matrix against the agreed scope through a retainer, which is optional and priced separately from the implementation. Confirm with us what a review covers, how often it runs, and how exceptions are approved and recorded before you sign.

ERPNext role permissions design