Why bother with approvals at all<\/h2>\n\n\n\n
Control, without the friction. That is the whole goal.<\/p>\n\n\n\n
You want a second pair of eyes on a large commitment. What you do not want is a document parked in somebody\u2019s inbox behind four hundred unread emails while a supplier waits on you.<\/p>\n\n\n\n
Acumatica keeps the entire thing inside the system. The approver gets notified, opens the document, sees the actual line items rather than a summary somebody pasted into an email, and clicks. The status changes on its own. The document either moves along to the next person or stops dead, depending on what you told it to do.<\/p>\n\n\n\n
The part that earns its keep is conditional routing. You are not stuck with one blanket rule for everything. Anything under five thousand dollars can go to Finance and be finished; anything above that can climb the ladder. The rules do the sorting so people do not have to.<\/p>\n\n\n\n
Groundwork you cannot skip<\/h2>\n\n\n\nEmployees and workgroups<\/h3>\n\n\n\n
Acumatica routes approvals to people, and it can only find those people when the employee record is properly linked to a user account. Miss that link and the workflow has nobody to notify. It fails silently too, which is the irritating part. Workgroups are worth setting up early. Assign a step to Finance rather than to one named person in Finance, and the approval does not stall the week that person is on leave. Anyone in the group can act on it. The catch is maintenance a workgroup nobody has touched in two years will happily route a $60,000 PO to somebody who left the company. I have shared the screenshot which covers the steps for creating a workgroup and adding members and owners to the company tree. <\/p>\n\n\n\n Dull, and skipping it will wreck your go-live. Acumatica needs working system email before it can notify anyone at all. Test it in a sandbox with a real send, not just a green tick on the SMTP screen. I have watched an implementation limp along for a week because notifications were failing quietly from day one and nobody noticed.<\/p>\n\n\n\n An Approval Map is your rulebook. You pick the entity type first for example Purchase Orders, AP Bills, Sales Quotes, whatever needs governing then build steps inside it.<\/p>\n\n\n\n <\/p>\n\n\n\n Each step holds conditions and actions. Read them as if-then pairs:<\/p>\n\n\n\n Condition: purchase order total over $10,000<\/em><\/p>\n\n\n\n Action: assign to the VP of Finance<\/em> A step can hold several of these, evaluated in order. If nothing matches, you decide what happens next: pass the document down to the following step, or reject it outright. Do not leave that blank. More on why below, because it is the single most common way these things break.<\/p>\n\n\n\n Three ways to name an approver, roughly in increasing order of cleverness.<\/p>\n\n\n\n Past about forty employees, pull the approver from the document wherever the data supports it. Otherwise you will spend the rest of your life editing approval maps every time somebody changes teams.<\/p>\n\n\n\n Say the requirement looks like this:<\/p>\n\n\n\n under $5,000 \u2192 Finance<\/em><\/p>\n\n\n\n $5,000 to $25,000 \u2192 Department Managerabove $200,000 \u2192 Department Manager, then Executive VP<\/em><\/p>\n\n\n\n That is three steps.<\/p>\n\n\n\n Step one catches the small stuff and finishes the workflow the moment Finance signs off. Step two handles the middle band and finishes once the manager approves. Step three also routes to the manager, but instead of finishing there it hands off, and the document travels on for the executive\u2019s sign-off.<\/p>\n\n\n\n Everything hinges on the step action. Tell the system to approve the document at step three and the executive never sees it \u2014 and you will believe multi-level approval is working right up until an audit says otherwise. Tell it to complete nothing and documents pile up in pending forever. Both mistakes are easy to make and neither one throws an error.<\/p>\n\n\n\n On each step you are choosing between three behaviours.<\/p>\n\n\n\n Match these to how your organisation actually decides things, not how the org chart claims it decides things. One signature per level? Complete Step. Genuine committee sign-off where it is everyone or nobody? Collect All Approvals, and be aware it is slower than people expect.<\/p>\n\n\n\n None of this works if the approver does not know there is something waiting.<\/p>\n\n\n\n Notification templates control who gets the email and what sits inside it. Include enough for a decision: amount, vendor, requester, and a link straight to the document. Resist the urge to dump every available field into the template. A wall of text gets skimmed, then ignored, then filtered.<\/p>\n\n\n\n Then check that notifications are switched on in module preferences. It is one checkbox. It is also, in my experience, behind a good third of the tickets that begin “the approvals aren\u2019t working”.<\/p>\n\n\n\n Four failures I have now seen often enough to predict.<\/p>\n\n\n\n If a document matches none of your conditions, it still needs somewhere to land. Build a catch-all step \u2014 call it No Approver Found \u2014 that either routes to a default approver or rejects the document. This is exactly what caused the eleven-day purchase order at the top of this post.<\/p>\n\n\n\n You can build a flawless approval map and watch absolutely nothing happen, because the map still has to be selected in the module\u2019s preferences screen. Building it is not the same as turning it on.<\/p>\n\n\n\n Employee from document only works when that field genuinely holds an employee ID. Point it somewhere else and approvals get skipped rather than failing loudly. Test with real transactions instead of a tidy demo record.<\/p>\n\n\n\n Somebody always wants a five-level chain. Two or three levels covers almost everything, and each extra level adds a day of latency and one more place for the document to stall.<\/p>\n\n\n\n Not every document needs formal sign-off. Sometimes a review is all anyone actually wants.<\/p>\n\n\n\n A workable approach is a custom checkbox field \u2014 Request Approval \u2014 used as a condition on the first step. Ticked, the workflow runs. Unticked, the document carries on. It is a small piece of customisation and it buys a surprising amount of flexibility, particularly with departments that resent approvals in the first place.<\/p>\n\n\n\n Acumatica sends one notification by default. If the approver ignores it, nothing further happens. The document simply waits.<\/p>\n\n\n\n Business Events solve this. Set one to find approvals pending beyond three days and send a nudge, then a second at five days that copies in the manager. Fifteen minutes of setup. On a couple of implementations it has cut average approval time by more than half, because people do respond to the second email.<\/p>\n\n\n\n One genuinely good thing about Acumatica is that these workflows do not live in isolation. Project approvals, change orders and purchase orders can be tied together, so a change order that blows the project budget gets caught before anybody commits the spend.<\/p>\n\n\n\n Anything more elaborate \u2014 checking spend against a GL account limit, for instance \u2014 usually needs a bit of custom code. Not much, but budget for it rather than discovering it three weeks out from go-live.<\/p>\n\n\n\n The configuration is the easy half. Working out what your business actually approves, at which thresholds, and who genuinely needs to see what \u2014 that is the part that takes time, and it is the part that decides whether any of this works.<\/p>\n\n\n\n Start smaller than you think you need to. Add a level when something goes wrong that a level would have caught. A workflow nobody complains about is doing its job.<\/p>\n","protected":false},"excerpt":{"rendered":"![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/1-2-1024x418.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/2-1-1024x443.png\")
<\/figure>\n\n\n\nSystem email<\/h3>\n\n\n\n
Building the approval map<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/3-1024x441.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/4-1024x446.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/5-1024x449.png\")
<\/figure>\n\n\n\nPicking who approves<\/h2>\n\n\n\n
\n
The multi-level part<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/6-1024x353.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/7-1024x378.png\")
<\/figure>\n\n\n\n What “approved” should actually mean<\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/www.greytrix.com\/blogs\/acumatica\/wp-content\/uploads\/2026\/08\/8-1024x472.png\")
<\/figure>\n\n\n\nNotifications<\/h2>\n\n\n\n
Where these break<\/h2>\n\n\n\n
No fallback rule<\/h3>\n\n\n\n
The map was never activated<\/h3>\n\n\n\n
Wrong field for the approver<\/h3>\n\n\n\n
Too many steps<\/h3>\n\n\n\n
Making approval optional<\/h2>\n\n\n\n
Chasing people<\/h2>\n\n\n\n
Things I would tell you over coffee<\/h2>\n\n\n\n
\n
Wiring it across modules<\/h2>\n\n\n\n
Last thing<\/h2>\n\n\n\n