Keep work moving without giving everyone the keys

At a glance

Frappe ERP separates role permissions from approval workflows: permissions govern access and actions, while workflows define the states and transitions a document follows. Use them together to make authority understandable. Start with ordinary staff accounts and a real decision, then prove both the work they need to perform and the actions they should be prevented from taking.

Start with the blocked request

A buyer needs to release an urgent order, but the manager who normally approves it is away. Somebody suggests giving the buyer a broad management role for the afternoon. The order might move, but that temporary shortcut can leave access behind long after the manager returns.

Design absence cover before the urgent order arrives. Frappe's role permissions and workflow transitions provide configurable controls for who can act and when. The benefit is a known route to a decision without treating unrestricted access as the only way to keep the business moving.

The sources here are Frappe's official version 13 documentation. Confirm the exact permissions and workflow behavior on your deployed release, including installed customizations. This is an implementation approach, not an assertion that a default role set satisfies your security or audit requirements.

Describe the job first

Write responsibilities as actions before translating them into role names. A buyer may need to prepare an order and read its receipt progress without being allowed to approve their own exception. A warehouse operator may need supplier identification without access to sensitive supplier information.

Frappe's Role Permissions Manager supports document permissions such as read, write and submit, with separate controls for actions including export and cancellation. These distinctions let you avoid the assumption that someone who can view a record should also be able to change or distribute it.

Prepare a small permission matrix with the business owner. Include ordinary work and explicit prohibitions. Name who approves each role's scope. If the team cannot agree whether an action is allowed, leave that as a business decision to resolve instead of asking the administrator to invent policy while configuring the screen.

Limit records deliberately

Role permission is only part of the design. Frappe also documents User Permissions for restricting access to particular documents, including linked-record effects, and permission levels for groups of fields. Use those tools where staff responsibilities are narrower than an entire document type.

For example, a branch user may need a restricted set of records while a central controller needs wider access. Demonstrate that distinction with representative users and real links between records. A role name containing branch does not prove that the person is restricted to that branch's transactions.

Test what happens beyond the normal menu. Open a direct record link and inspect relevant reports or exports. Removing a navigation item is not evidence that access is denied. Include the integration identity if another system posts records; a carefully restricted human workflow does not prove that every alternate entry point follows the same rule.

Make approval states readable

Frappe workflows define states and transition rules, with conditions determining when a transition applies. Give those states names that staff can explain. Waiting for finance approval should identify an actual pending decision, not become a permanent label nobody owns.

A workflow is not a second copy of the permission matrix. The buyer needs access to prepare the document, while the approval route determines the next allowed decision. Review both layers together. A permitted transition is no help if the intended approver cannot read the document required to make it.

Keep thresholds explicit, including their currency basis. An authority policy stated in one currency needs a defined treatment for foreign-currency orders. Ask finance to approve the field and conversion basis used by the condition. Do not copy a number into a rule and assume every transaction interprets it the same way.

Test the awkward paths

Frappe's documentation warns that a configured workflow overrides the normal Save and Submit flow. Cancellation must be included as an appropriate transition when required. Test rejection, correction and cancellation rather than accepting a demonstration that ends at approval.

A rejected order should leave its preparer with a clear action. If the buyer corrects the amount, demonstrate who must approve it next. If the commercial commitment has already been sent to the supplier, your operating procedure must also address that external communication; a system state change alone cannot withdraw the supplier's understanding.

Test coverage example, hypothetical and not an ERPNova result: four role profiles each exercise five allowed or forbidden actions, producing 20 checks. Repeating that matrix after an approval-rule change gives another 20 checks, or 40 executions in total. These are repeated checks, not 40 distinct business controls. Keep expected and actual outcomes beside every result.

Run the tests with non-administrator accounts. A consultant demonstrating both sides while signed in with broad privileges cannot prove the boundary you are paying to establish.

Make cover expire

Name a substitute approver and the period of cover. Decide who grants temporary access and who removes it, then retain evidence that removal happened. Keep the coverage procedure short enough for a supervisor to follow during an actual absence.

Review access when someone changes jobs, not only when they leave. A former buyer who moves into sales may retain purchasing authority unless somebody checks the combined roles. Make the review about current responsibility instead of assuming historical access is harmless because it has never caused an incident.

Bring ERPNova an authority policy and an example of a delayed approval to an ERP audit. Ask for a Frappe ERP demonstration using ordinary accounts, including an absent approver and a rejected request. For requirements beyond configuration, our customization guide explains how to define the additional logic and its maintenance owner before commissioning it.