Too Many Epicor Approvals—or Not Enough? How Do You Design the Right Control?
Approval workflows fail when they become either ceremonial clicks or uncontrolled gaps. The right Epicor approval design matches decision consequence, authority, threshold and exception handling.
The short answer
An Epicor approval workflow should exist only where a real business decision needs additional authority. Too many approvals turn into routine clicks; too few approvals leave material decisions uncontrolled. The right design links approval to consequence, threshold, role, evidence and exception handling.
The objective is not to maximize the number of approval steps. It is to place deliberate decisions where they genuinely reduce risk.
How this connects to the pillar
The broader control model is covered in Epicor Is Full of Controls. How Do You Know They Still Match the Way the Business Operates?. Approval workflow is one example of a control that can remain technically active while losing practical value.
Start with the decision that needs authority
Before designing routing, define what the approver is responsible for deciding.
Is the approver checking commercial value, budget availability, price variance, supplier choice, customer credit, unusual terms or a policy exception?
Different decisions require different evidence.
If the purpose is vague, the approver is likely to click through the task without adding meaningful control.
Use thresholds to separate routine from exceptional
A common approval problem is asking senior people to review low-consequence routine transactions.
That creates queue delay and weakens attention. When every transaction requires approval, important transactions do not stand out.
Thresholds can be based on value, variance, risk category or another business factor that reflects consequence.
The threshold should be reviewed periodically because transaction values and responsibilities change.
Make authority follow the organization
Approval design should reflect who actually owns the decision.
If an approver leaves, moves role or changes responsibility, the workflow should not continue routing important decisions to an inappropriate person simply because the configuration still works.
Delegation and temporary cover also need rules.
A temporary substitute should know what authority is being delegated and for how long.
Give approvers the evidence they need
An approval task without context creates weak decisions.
The approver may need to see value, requester, supplier, item, variance, previous approval, budget or other relevant evidence.
The right information depends on the decision.
Avoid forcing approvers to open multiple unrelated screens or ask for information outside Epicor whenever the evidence can be presented as part of the controlled workflow.
Avoid approval loops caused by poor upstream data
Sometimes an approval is added because upstream data is unreliable.
For example, management may require repeated review of orders because prices are frequently wrong, or require supervisor approval because master data does not reliably enforce a rule.
That may be necessary temporarily.
But if the real cause is data quality or process ownership, approval becomes an expensive substitute for fixing the source.
Track why approvals are rejected or returned so recurring causes can be improved.
Distinguish approval from notification
Not every important event needs someone to click approve.
Some events need visibility rather than authorization.
A manager may need notification of a threshold breach or unusual transaction while allowing the process to continue. Turning every notification into a hard approval can slow operations without increasing control.
Choose the mechanism that matches the intended management response.
Design escalation before queues become invisible
Approvals can become operational bottlenecks when tasks sit with unavailable people.
Define what happens when an approval is not completed within an acceptable time. The answer may be escalation, delegation or reassignment.
The escalation path should preserve authority rather than simply routing around the control.
A useful workflow makes stalled approvals visible before users create manual workarounds.
Use rejection data as improvement evidence
Rejected approvals contain useful information.
If the same reason appears repeatedly, the organization may have a process, data or training issue upstream.
Examples include repeated price variance, incorrect supplier selection, missing documentation or transactions submitted outside policy.
Approval reporting should therefore look beyond how many tasks were approved. It should analyze what the control is repeatedly catching.
Test whether the approver is independent enough
An approval adds limited control if the approver has effectively already made the same transaction decision.
For high-risk activities, consider whether the approval provides meaningful independence.
The correct design depends on the organization, but the principle is that the second decision should add something the first action did not.
Keep emergency override visible
Operations may occasionally need to bypass normal approval timing.
If emergency override is allowed, define who can use it, what evidence is required and how it is reviewed afterward.
An emergency path should not become the fastest normal path.
Repeated emergency use is a signal that the standard workflow may be poorly designed.
What management should measure
Useful measures include:
- approval volume by process;
- average approval delay;
- percentage approved without change;
- rejection reasons;
- repeat rejection causes;
- emergency overrides;
- approvals performed by delegates;
- approvals waiting beyond expected time;
- transactions below or above thresholds;
- approvals with no clear business owner.
These measures help determine whether the workflow is controlling risk or merely adding clicks.
ACC context
ACC supports Epicor process design and ongoing improvement. Approval workflows are strongest when they reflect real decision authority and business consequence, not when they are added simply because the system can route them. Explore ACC’s Epicor capabilities.
Operational review point
Choose one approval workflow with high volume.
Sample recent transactions and ask three questions: what decision was the approver expected to make, what evidence did they use, and what changed because of the approval?
If the answer is consistently “nothing,” the workflow may be ready for redesign.
If rejections cluster around the same cause, the improvement may belong upstream rather than in the approval step.
Revisit approval design after organizational change
A workflow may remain technically correct after the organization changes while routing decisions to people who no longer own the consequence. New business units, acquisitions, decentralization or centralization can all change who should approve.
Include approval ownership in organizational-change reviews. It is easier to update the routing when responsibilities move than to discover the mismatch later through delay or inappropriate approval.
Make approval data useful for capacity planning
Approval queues can also reveal whether authority is concentrated too heavily in one role. If one manager receives a disproportionate volume of routine approvals, the business may need different thresholds, delegated authority or clearer policy.
The objective is not simply faster approval. It is to place decisions at the lowest appropriate level while retaining control over material exceptions.
Use approval thresholds that reflect cumulative exposure
A transaction can fall below an approval threshold and still create material exposure when many similar transactions occur together.
Depending on the business risk, management may need to consider cumulative value, repeated exceptions or category-level exposure rather than only the value of one transaction.
This does not mean every approval workflow needs complex aggregation.
It means threshold logic should be chosen because it represents the risk, not because one numeric field is easy to configure.
Design the return path
A rejected approval should not simply stop the process.
The requester should know what needs to change, whether the transaction can be corrected and resubmitted, and whether the original evidence remains visible.
Poor return paths encourage users to create a new transaction or solve the issue outside the workflow.
A good approval control therefore includes the correction loop as part of the process.
Review approval authority against access authority
Approval authority and transaction access should be considered together.
If the same user can create, materially change and approve a high-risk transaction, the approval step may add little independence.
Where overlap is necessary, use compensating review proportionate to consequence.
This connects approval design directly to user-access governance rather than treating the two controls separately.
Test approval design with real examples
Before changing thresholds or routing, take several recent transactions and replay the proposed design. Include a normal case, a borderline case, a rejected case and a genuine exception.
This reveals whether the proposed workflow places authority correctly without forcing users into unnecessary escalation. It also gives approvers a concrete way to confirm what they are expected to decide.
Frequently asked questions
Should every high-value transaction require approval?
Not automatically. Value is one useful risk indicator, but decision type, variance, policy and user authority may also matter.
Is an approval still useful if almost everything is approved?
Possibly, but near-automatic approval is a reason to test whether the control is adding real judgment.
Should notifications replace approvals?
Use notification when management needs visibility but not authorization. Use approval when a second decision genuinely needs to control the transaction.
How should delegation work?
Delegation should be time-bounded, visible and given to someone with appropriate authority for the decision.