ERPNext automation: which tool fits which routine step
Finance and operations teams often lose hours each week chasing sales orders waiting for approval, purchase requests sitting unassigned, and invoices that nobody has followed up. ERPNext gives you several automation tools, and each one fits a different kind of step. Notifications send an email or system alert when a document event occurs, such as a submitted sales order or an overdue approval. Assignment rules route newly created or changed documents to a user or group, so work lands with a named owner instead of in a shared queue. Webhooks push document data to an external system when an event fires. Server Scripts run Python on document events or expose API endpoints, and Automation Flows chain several steps together with waits and branches.
A useful first step is to map each manual follow-up to the single action it needs. If the problem is that nobody knows a request exists, a notification or assignment rule is usually enough. If the step must reach another system, a webhook or integration fits better. If the logic depends on field values and must run on save, a Server Script may be the right tool, but it has conditions: since version 15 it is disabled by default and must be enabled with server_script_enabled, and Frappe Cloud public shared benches do not allow it. Confirm this in your hosting environment before designing around it. Multi-step processes with time-based follow-ups are where Automation Flows belong, and their exact trigger and step options should be checked against the ERPNext version you run.
Each tool adds maintenance. Notification templates, rule conditions, scripts and flows all change when document fields or approval policies change, and they must be tested in a non-production site before a release. Ask your partner to document which automation sits in the database and which is shipped in code, because that determines how it moves between environments. Start with the one follow-up that costs your team the most time, automate it with the simplest tool that works, and expand only after the first flow has run through a full business cycle.
Choosing between notifications, assignment rules, webhooks, server scripts and Automation Flows
Notifications send an email or system alert when a document meets a condition you define, such as a sales order being submitted or a purchase request waiting for review. They are configured in the desk without code, which makes them the lightest option when the goal is to tell people that something happened.
- Trigger: document events such as insert, save, submit or cancel, evaluated against a condition written into the notification.
- Sends: an email to users, roles or an address stored on the document, using a subject and message template that pulls in document values.
- Fits: informing a stakeholder of a status change when no record needs to change and no one needs to respond inside ERPNext.
- Stops fitting: when the message depends on several steps, must update data, or has to wait for an answer before the next action.
- Watch: recipient lists and template fields go stale after role changes, so review them during staff moves.
Confirm that outgoing email from your environment reaches recipients reliably, and test each template against sample documents before go-live.
Assignment rules decide who should act on a document next. When a document is created or changes, the rule adds an assignment (a ToDo) to a user, either from a field value or by rotating through a list of users. Use them when the open question is ownership, not approval or data change.
- Trigger: document creation or update where the rule's condition matches.
- Changes: adds an assignment to a user and can reassign when a monitored field changes. Round-robin distribution across a user list is available for queue-style work.
- Fits: routing support cases, purchase requests or leads to an owner based on territory, company, product line or category.
- Stops fitting: when the owner depends on amount thresholds, multi-level sign-off, or timed escalation with reminders.
- Watch: confirm how existing assignments behave when a user is disabled or leaves, because open items may stay with that user until someone reassigns them.
Review the rule conditions with the operations team that owns each queue, and confirm the exact round-robin and reassignment behavior in your ERPNext version before relying on it for workload distribution.
Webhooks send a JSON payload to an external URL when a document event occurs, so another system can react. ERPNext does the sending and the receiving system decides what to do with the data. They suit one-way notifications to systems outside ERPNext, such as a warehouse service, middleware or a chat channel.
- Trigger: document events configured per DocType, such as create, update, submit, cancel or delete.
- Sends: the document data as JSON to a URL you specify, with optional headers and conditions. Confirm the exact payload fields and header options for your version.
- Fits: telling a fulfillment system that a sales order was submitted, or posting a summary to an operations channel.
- Stops fitting: when the receiver needs delivery guarantees, retries, field mapping, or writes back into ERPNext. Those needs belong in an integration layer that handles failures and mapping.
- Watch: the receiving endpoint becomes part of your control scope, so secrets in headers, TLS certificates and access logs need the same handling as other integration credentials.
Confirm how failed deliveries are reported in your environment and who monitors them, since a webhook that fails silently creates gaps the business only discovers later.
Server scripts run restricted Python on document events or expose an API endpoint, without a custom app. They can validate input, calculate values and change documents, which makes them the first place teams look when the desk settings cannot express a rule. From version 15, server scripts are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all.
- Trigger: before or after document events, or a call to an API endpoint the script defines.
- Changes: can read and write documents, raise validation errors, and call functions permitted in the restricted execution environment.
- Fits: short validations or derived values on one DocType, owned by a small group who can review the code.
- Stops fitting: logic that spans many DocTypes, needs external libraries, runs long, or needs automated tests and version control. Move that logic into a custom app.
- Watch: enabling the setting applies to the whole site, so it is an administrator decision. If you host on Frappe Cloud public shared benches, plan a different hosting option before you design around server scripts.
Read the Frappe server script documentation and confirm the setting on your own bench before you design any process that depends on it.
Automation Flows chain several steps into one process, with waits and branches between them. They fit processes that run over days, involve several people and need a decision at each stage. Confirm which ERPNext release provides Automation Flows and check its current options in your version, since availability and step types change between releases.
- Trigger: a document event or schedule that starts the flow, with conditions that decide whether it runs.
- Changes: runs a sequence of actions such as sending messages, setting values or creating assignments, with waits and branches between steps.
- Fits: multi-step approvals or reminders where a later step depends on a date passing or a response arriving, and each branch must leave a visible record.
- Stops fitting: complex transaction logic, high-volume bulk processing, or work that needs custom error handling and tests. Those cases belong in a custom app or an external orchestrator.
- Watch: decide who owns each step, how paused flows are reviewed, and what happens to waiting items when the owner leaves the company.
Test every branch with sample records, and document the flow next to the business process it supports so that reviewers can check the logic without reading the configuration.
Automation options compared by trigger, effort and risk
This table compares notifications, assignment rules, webhooks, server scripts and Automation Flows by what starts them, who maintains them, where the logic runs and how exposed they are to upgrades. Read each row as a question to answer for your own process before choosing a mechanism. The main takeaway is that the simplest option that meets the requirement usually carries the least upgrade and support risk.
| Option | Trigger and typical use | Who maintains it | Where logic runs and upgrade exposure |
|---|---|---|---|
| Notifications | A document event or scheduled condition sends an email or system alert to users or roles | Functional admins, configured in the UI with no code | Inside ERPNext configuration, low upgrade exposure, but volume and recipient rules need periodic review |
| Assignment rules | A new or changed document is assigned to a user or role based on field values | Functional admins, configured in the UI | Inside ERPNext configuration, low exposure, but fairness and load rules need checking after role changes |
| Webhooks | A document event sends data to an external system over HTTP | Integration engineers, with the receiving system owned elsewhere | Logic runs in the external receiver, so receiver changes and endpoint availability need their own change control |
| Server scripts | Python on document events or as API endpoints for logic that notifications cannot express | Developers, and a technical owner for each script | Runs on the ERPNext server, must be enabled in version 15 and later, and is not available on Frappe Cloud public shared benches |
| Automation Flows | Multi-step sequences with waits and branches, started by document changes or schedules | Functional admins for simple flows, developers for complex branches | Configured in ERPNext, so steps need testing after each upgrade because flow behavior can change between releases |
| Custom app code | Logic that must be versioned, tested and deployed with the rest of the system | Developers, through a repository and release process | Lives in source control and deploys with the app, which gives the clearest audit trail and the most upgrade work to plan |
| Choose notifications or assignment first | Requirement is a message or a routing decision on one document type | Business owner with the functional admin | Confirm the trigger and recipients in writing before adding any scripting |
| Choose Automation Flows or code | Requirement spans several documents, approvals or waits | Process owner with a technical reviewer | Confirm which version of ERPNext the flow targets and test it against a copy of production data |
How to build and test an automation in ERPNext
This sequence turns a routine manual step into an ERPNext automation that is documented, tested with a named user, observed in its run log, and promoted to production through version control. It keeps the team from discovering side effects in live accounting or stock records.
Write the routine step on paper
Before opening ERPNext, write the step as a short sequence: the trigger document and its status, the condition that must be true, the action taken, the person or role who should be told, and what must not happen. Name the DocType and the fields involved, and list the users who currently perform the step by hand. Confirm with the process owner whether the step is a notification, a routing decision, a status change that needs several approvals, or a sequence that waits for an external event. The output is a one-page specification that the finance, stock or sales owner signs off. If the owner cannot describe the exception cases, the automation is not ready to build.
Pick the lowest-risk mechanism
Choose the simplest ERPNext feature that meets the specification. A Notification fits an email or system alert on a document event. An Assignment Rule fits routing a document to a user or role based on its fields. A webhook fits sending a document event to an external system. A Server Script fits custom Python on a document event or as an API endpoint, but it must be enabled with the server_script_enabled setting on version 15 and later and is disabled by default. An Automation Flow fits multi-step logic with waits and branches. Prefer the mechanism that changes the fewest records and is easiest for your administrators to review. Confirm in your own version whether the feature you need is available and where it lives in the menu.
Build the automation in a staging site
Create the automation on a staging site that runs the same ERPNext version, apps and relevant master data as production. Do not build directly in production. Keep the rule narrow at first: restrict the condition to one company, one warehouse or one document series so that a mistake touches little. Record each setting you choose, including the notification recipients, the assignment condition or the flow branches. The output is a staging configuration that matches the specification step by step. If you rely on a Server Script, confirm that your hosting environment allows it, because Frappe Cloud public shared benches do not allow Server Scripts.
Test with a named user and a non-production record
Create or pick a test user with the same role and permissions as the person who will trigger the step, then perform the action as that user on a non-production record. Test the normal path, each branch and each exception case from the specification, including a record that should not match the condition. Confirm that the notification reaches only the intended recipients, that the assignment lands on the right user, and that a flow waits and resumes as expected. Check that the test user cannot see or change anything beyond the intended scope. The output is a test log with the document name, the user, the expected result and the observed result for each case.
Check the log of each run
After each test, review the record that ERPNext keeps for the automation: the notification log, the assignment history, the error log and, for flows, the execution state of each step. Look for silent failures, duplicate sends, retries and errors that appear only on some documents. Confirm that a failure in the automation does not block the underlying document from saving, or, if it should block, that users receive a clear message. Repeat the test after any change. Record the log locations in your runbook so that the team that supports production knows where to look. The output is a clean run log for every case in the test plan.
Promote the automation through version control
Move the tested configuration out of the database and into version control so that production receives the same definition as staging. Where the automation is stored as configuration, export it with the customization mechanism your team uses and review the diff before merging. Where it is a Server Script or part of a custom app, keep it in the repository with the rest of the code and deploy it through the normal release path. Confirm how your version exports and syncs these records, and plan for the overwrite behaviour before the first sync. The output is a reviewed change in the repository and a production deployment that matches the tested staging definition.
Verify the first production runs and record ownership
After promotion, watch the first real runs with the process owner and the administrator. Compare the notification log, assignments or flow state with the expected outcomes from the test plan, and confirm that no unintended records were touched. Record who owns the automation, who can change it, how it is disabled in an emergency, and what to check after each ERPNext upgrade or app change. Automations that depend on Server Scripts or external webhooks need a named owner for those dependencies as well. The output is a signed-off production check and a runbook entry that names the owner, the rollback step and the upgrade check.
Where ERPNext automations go wrong in practice
Most automation failures in ERPNext are not technical surprises. They are ownership gaps: a notification nobody can explain, an assignment rule that sends a document back and forth between two users, or a flow that waits for a status field that a retired process no longer sets. Before building anything, record a named owner for each notification, assignment rule, Server Script, webhook and Automation Flow, along with the DocType it touches and the business outcome it protects. Duplicated notifications usually come from two triggers firing on the same document event, such as a Notification and a Server Script both sending an email on submit. Assignment loops usually come from rules that reassign on save without a condition that stops re-triggering. Review both during a staged rollout on a test site with realistic records before enabling them in production.
Server Scripts deserve the closest review at upgrade time. They are Python that runs on document events or as API endpoints, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Confirm that the setting is on in every environment where scripts run, keep a list of every script with its DocType and event, and add them to your upgrade test plan so that regressions show up on staging rather than in month-end processing. Webhooks fail silently when the receiving system is down unless you monitor delivery, so decide who sees failed deliveries, how they are retried, and what happens to the business process if an event is lost. Flows that wait on conditions need a periodic check that the waited-for state can still occur. Logging each run and reviewing the Error Log and webhook history on a fixed schedule turns these silent failures into visible tickets.
Security and operational risks of automated actions
Automations in ERPNext act on documents without a person clicking anything, so they inherit permissions, credentials and timing in ways that are easy to miss. The cards below cover the points a security or platform team should review before switching an automation on in production.
Permissions the automation runs under
Notifications, assignment rules and automation flows act with the permissions of the user who triggers them or, for scheduled and background work, with a designated user. Confirm which user runs each automation and whether that user can read or change documents it should not touch. An assignment rule that reassigns invoices to a user with broader roles can quietly widen access. Review each automation's owner and role set as part of change control.
Credentials in webhook headers
Webhooks often carry API keys, bearer tokens or signing secrets in request headers. Anyone with access to the Webhook configuration, to a database backup or to a log that records outgoing requests may read them. Store the least-privileged token the receiving system accepts, rotate it on a schedule, and confirm which roles can open the Webhook DocType. Ask the receiving team whether they validate a signature so a forged request cannot trigger the same action.
Server script reach on self-hosted benches
Server Scripts run Python on document events and as API endpoints, and from version 15 they are disabled by default until server_script_enabled is set. On a self-hosted bench, the scripts run inside the restricted environment, but their effect still spans every document the executing user can reach. Decide who may create or edit Server Scripts, require review through your app repository, and record which sites have the setting enabled. Public shared benches on Frappe Cloud do not allow them, so a design that depends on them needs a different host.
Audit trail for automated changes
When an automation edits a document, the change should be traceable to the rule or script that made it. Check whether the document's version history records the automated change and which user it ran as, and whether your logs keep the webhook request and response. Without this, a wrong status change or a mass reassignment is hard to explain to auditors or to reverse. Agree on a retention period for those logs with your compliance owner and confirm it with your hosting provider.
Dependence on the scheduler
Scheduled notifications, date-based assignment and time-based flow steps depend on the background scheduler and workers running. If the scheduler stops, reminders and escalations silently stop firing, and documents may sit unassigned with no visible error. Monitor scheduler and worker health, alert on queued jobs that do not complete, and test what happens after a restart. Confirm with your team how a missed run is recovered and who is paged when it fails.
Multi-step flows and change control
Automation Flows with waits and branches can run for days and react to records changed by other people or other automations. A branch that reopens a document can trigger another rule, producing loops or duplicate messages. Keep flow changes under version control where your setup allows, test each branch with sample records in a staging site, and list which other automations touch the same DocTypes before release.
Questions buyers ask before automating ERPNext
How much effort does ERPNext automation usually take?
Effort depends on how many steps are automated, how many people approve or receive them, and how many documents and branches the logic must handle. A single notification on one DocType is a small change. A multi-step flow that routes a sales order through credit checks, stock reservation and approvals touches accounting, stock and user roles, so it needs design, testing and sign-off across those areas. Ask any quote to break effort into discovery, build, testing, deployment and handover, and to say which parts recur, such as reviewing flows after each ERPNext upgrade.
What drives the cost of an ERPNext automation project?
The main drivers are the number of processes, the number of exceptions each process must handle, the roles that act on each step, and how much the flow depends on external systems. Cost also rises when the process is not agreed before build starts, because rework follows. Licensing is not the main driver: self-hosting ERPNext is free according to the ERPNext pricing page, so the cost sits in design, build, testing, hosting and support. Hosting on Frappe Cloud has published starting prices, shared site hosting from 5 US dollars per month and servers from 20 US dollars per month for shared instances, but those figures exclude your build work.
How long does a typical ERPNext automation build take?
No duration is fixed across projects, so treat any single number with caution. The timeline follows scope: a few notifications on existing documents move quickly, while a flow that spans several DocTypes, waits for approvals and calls an external API needs more discovery, test cases and a staged rollout. Ask for a written scope with milestones, the test environment you will use, and the point at which users begin acceptance testing. Scope agreed in writing before work starts makes the schedule easier to hold.
What does our team need to provide for automation work?
The work needs a named process owner who decides how the business process should behave, a user who can test each branch, and an administrator who can grant access to a staging site. Engineers need the current ERPNext version, the list of custom fields and scripts already in place, and any integration endpoints with their authentication method. Your team should also confirm who approves changes to production and how they will review automation logs after go-live.
Can internal staff build simple ERPNext notifications themselves?
Yes, for simple cases. ERPNext lets administrators create notifications and assignment rules from the interface, so a trained administrator can handle a basic alert when a document reaches a status or an assignment to a user based on a field value. The risk grows when a rule has conditions on linked documents, sends email to external parties or depends on other rules. Test every rule on a copy of production data, document who owns each rule, and record changes so that a later upgrade does not surprise the team.
What goes wrong when ERPNext automations are built without a plan?
Common problems include duplicate notifications, assignment loops where two rules reassign the same document, flows that stall at a wait step with no owner, and server logic that fails silently. Server Scripts also need attention: according to the Frappe documentation, they are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Plan for error visibility, a documented owner for each automation, and tests that cover rejected and cancelled documents.
When should we bring in a partner for ERPNext automation?
Bring in a partner when the process crosses several modules, when automation must call external systems, when the logic needs a custom app rather than configuration, or when your team lacks time to test and maintain flows. A partner is also useful when you need a fixed-scope delivery with written deliverables and a support plan after go-live. DeployOpen implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with a quote following from the written scope.
What your team owns after automations go live
Once notifications, assignment rules and Automation Flows are live, the build is the smaller part of the work. Your team owns the behaviour from that point on, and the first thing to plan for is who reviews notification recipients and assignees when people change roles. Notifications and assignment rules point at roles, users and fields on documents, so a reorganization can silently send approvals to someone who no longer holds the job. Assign a named owner for each automation, record what it is meant to do, and review the recipient list on a fixed schedule and whenever a team changes. Ask your implementation partner to document these owners as part of the handover, not as an afterthought.
Every ERPNext minor release is a point where automations need a fresh check. The frappe/erpnext releases page shows that both supported major versions, v15 and v16, receive frequent minor releases, and the Frappe supported versions page states that ERPNext and Frappe Framework version 14 has reached end of life. Keep your production major version on a listed release, and plan a retest of each notification, assignment rule, Server Script and Automation Flow in a staging site before each minor update reaches production. Frappe's supported versions policy also ties warranty coverage to a listed version and a matching Frappe Cloud support plan, so confirm which of those conditions applies to your deployment before you schedule upgrades.
Scripts and flows should live in version control, not only in the database. Export the automation records and any Server Scripts into a custom app or an agreed folder, review changes through the same process your team uses for code, and promote them between sites the same way. Monitoring matters just as much: check the Error Log and the email queue regularly, and make sure someone is notified when a scheduled or event-driven automation fails. A failed approval step that nobody sees is a process defect, and it will look like one to your auditors.
How DeployOpen scopes and delivers ERPNext automation
This sequence turns a list of routine ERPNext steps into a written scope, tested automations and handover notes your team can run and change. Each step ends with a check you can review before the next one starts.
Inventory the manual steps and owners
DeployOpen starts with your team's current routine work: who creates which documents, who approves them, which emails go out and where people wait for someone else. We record each step against the DocType it touches, the role that performs it and the business rule behind it. The output is a process inventory your finance, stock or production leads can confirm line by line before any automation is designed.
Classify each step by mechanism
Each inventoried step is assigned to the ERPNext mechanism that fits it: a Notification for an email or alert on a document event, an Assignment Rule for routing a document to a user, a webhook for pushing data to an outside system, a Server Script where a small piece of logic is enough, or an Automation Flow where several steps need waits or branches. Steps that do not fit any of these are flagged for a custom app or left manual. The classification is written into the scope so you can see why each choice was made.
Write the scope document
DeployOpen writes the scope as a single document listing every automation by name, its trigger, its conditions, the roles it affects, the systems it touches and what is out of scope. Deliverables, acceptance checks and the handover items are listed beside each automation. The scope is agreed in writing before build starts, and any later change is handled as a written change to that document. Confirm with us which Server Script settings and hosting constraints apply to your environment before this step closes.
Build in a non-production site
The automations are built on a staging site that mirrors your production configuration, including roles, naming series and the apps you run. Notifications, Assignment Rules and Automation Flows are created and exported where your version control process requires it. Server Scripts are only built if your deployment allows them. The output is a staging build that matches the scope, with each automation traceable to its line in the scope document.
Test with representative records
DeployOpen tests each automation with representative records that cover the normal path, the branches, the edge cases and the cases that should not trigger. For Automation Flows, waits and branches are tested with dates and states that move the record through each path. Test records and the expected result of each run are kept in the test log. Failures are fixed and retested. The output is a test log showing each automation's expected and actual behavior.
Confirm acceptance with your owners
Your named process owners run the acceptance checks written in the scope against staging. They confirm that each notification reaches the intended recipients, that assignment rules route documents to the right users and that flows stop or continue where the scope says they should. Sign-off is recorded per automation. The output is a signed acceptance list, and any item that fails is returned to the build step rather than accepted with a note.
Deploy and hand over
The approved automations are moved into production through your change process, with the deployment steps recorded. DeployOpen delivers handover notes covering each automation's purpose, its trigger, the roles it depends on, how to disable it, how to change its conditions and which items need a periodic check. Your administrators receive these notes and a walkthrough. The output is a live set of automations and a handover pack that your own team can maintain.
Agree retainer options for ongoing changes
Routine work after handover, such as new approval steps, changed owners or adjustments after an upgrade, can stay with your team or move to a retainer agreed in writing. Ask for the retainer scope, response expectations and how changes are logged before you sign. Each change is recorded against the scope document so the automation inventory stays current. The output is a maintained inventory that reflects what is running in production.
