An approval workflow needs a decision owner, clear criteria, and a path for changes or absence. A button labeled approve does not define the operating process.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Model the decision
Identify what is being authorized and what information the reviewer needs. A purchase request may require different evidence from a schedule change. Record possible outcomes such as approve, reject, or return for clarification. Explain whether the requester can edit the item while the decision is pending.
For a purchase request, keep the project, supplier, quotation, items, quantities and total on the same review record. An approval should identify the version being authorized and the person who can release the order to the supplier. Approval, order release and receipt of goods are separate events.
NovaPro, a procurement platform we developed, connects orders with suppliers, project information and purchasing documents. Its public product description includes status and approval tracking. The decision rules in the example below are a proposed scoping exercise; they do not describe a verified NovaPro customer configuration.
Handle reassignment
Decide who can act when the normal reviewer is unavailable and how the substitution is recorded. Avoid sharing accounts to keep work moving. If the business uses approval thresholds, specify where those rules are maintained and who can change them. The system should make the applicable rule understandable at the time of review.
Write the approval matrix before building the screen. Replace the role names below with the people or groups authorized by your business, and agree on any amount limits. An overdue request should reach the named substitute or process owner; elapsed time alone should not approve a purchase.
| Purchase request situation | Decision and owner to define | Evidence to retain |
|---|---|---|
| Complete request within the agreed limit | The designated approver reviews the need and quotation. | Request version, supplier, total, approver and decision time. |
| Request above the agreed limit | Route to the additional authorized approver before order release. | The applicable limit and each required decision. |
| Missing quotation or project | Return to the requester with the missing information identified. | Return reason and the revised submission. |
| Usual approver unavailable | Assign the authorized substitute using their own account. | Who reassigned the request, to whom and why. |
| Supplier, quantity or price changes after approval | Pause release and request a decision on the revised version. | The old approval, changed fields and new decision. |
| Order already sent to the supplier | The purchasing owner handles an amendment or cancellation with the supplier. | The sent order, requested change and supplier response. |
Treat changes deliberately
A material edit after approval may require a new decision. Define which fields trigger that behavior and preserve the approved version. Otherwise a record can display approved while representing something the reviewer never saw. Keep routine corrections distinct from changes in the substance of the request.
For example, a requester changes an approved order from 10 items to 15. Keep the original 10-item version and its approval in the history, mark the 15-item version as awaiting review, and prevent it from being released under the old approval. If the supplier already received the order, record a separate amendment and its response instead of silently replacing the sent document.
Run an acceptance exercise
Submit an ordinary request, return one for clarification, and reassign one during an absence. Then change an approved item and inspect its history. If the business cannot explain which version was approved and by whom, the workflow is missing a control that should be resolved before launch.
Use one sample order for the whole exercise. Have two reviewers open the same version, then edit the quantity before either confirms. The expected result is a visible request to review the changed version, not an approval attached to unseen data. Repeat the submit action and check that it creates only one request. Confirm that an unauthorized account cannot approve it.
Before a pilot, record the current time from submission to decision, the number of clarification rounds and the requests waiting without an owner. Measure the same items during the pilot, including time spent resolving exceptions. These observations can show whether the new process helps; they are not claimed results from NovaPro.