RESOURCES / WORKFLOW WALKTHROUGHS
An approval workflow example: intake to decision
This worked example follows a fictional internal service request. It is an educational process model using invented records—not a client case study, functioning demo or adopted operating procedure. Adapt the rules and approval authority before using it in an organization.
Set up the record and roles
Request R-104 asks for a review of a draft project brief. Its record contains request ID, requester, service category, summary, requested date, attachment reference, current status, assigned coordinator and decision history. Only information necessary for the task belongs in the record.
The requester supplies and corrects information. The coordinator checks completeness and routes work. The reviewer records an approval or rejection. The administrator manages permitted access but does not automatically gain business approval authority. In this example, a requester cannot approve their own request.
Step 1: Submit and acknowledge
The requester submits R-104 with a summary and draft attachment. The system assigns an ID and records Submitted. The acknowledgement identifies the request; it does not promise acceptance or a delivery date.
A submission check confirms required fields and attachment reference are present. This checks completeness, not whether the contents are accurate or the work is appropriate.
Step 2: Check and route
The coordinator confirms that the request belongs to the selected category and that the linked draft is available to the reviewer. The coordinator assigns a reviewer and records Under Review.
The handoff contains the request ID, current draft version, review question and any known constraints. Internal routing notes remain separate from requester-visible comments.
Step 3: Record the decision
The reviewer examines the specified version and chooses Approved or Rejected with a reason. The decision record includes the reviewer, time, version and outcome. The request’s status changes only after the decision is saved.
Approval here means the draft is accepted for the next agreed step. It does not itself authorize spending, begin delivery or confirm a contract. Those are separate decisions unless an actual process explicitly connects them.
Step 4: Notify and verify completion
The requester receives the decision or can inspect it through an authorized view. The coordinator checks that the decision is recorded against the correct request and version. A failed notification leaves the saved decision intact and creates a notification issue to resolve.
The normal-path result is one request, one recorded decision for the reviewed version and a visible next action. Completion is not measured by whether an email alone was sent.
Exception: information is missing
If the attachment is absent, the coordinator records Needs Information, names the missing item and returns the request to its owner. The request is not rejected merely because it is incomplete.
When the requester supplies the missing item, the coordinator repeats the completeness check. Keep the earlier reason in history so the next reviewer can understand the delay.
Exception: duplicate or repeated action
If a second submission appears to describe the same work, compare the requester, subject and referenced material before linking or closing it as a duplicate. Similar wording alone is not enough to discard a request.
If an approval action is retried after an uncertain response, check the existing decision first. The desired behavior is to return the existing result rather than create another approval. Whether a particular platform supports this must be verified.
Exception: reviewer absence or changed scope
An absent reviewer leaves the request waiting with an accountable coordinator. Reassignment must go to an authorized replacement and be recorded; a deadline does not justify bypassing approval.
If the requester replaces the draft after approval, create a new reviewable version and mark the earlier decision as applying to the old version. If the request is withdrawn, record Withdrawn and stop pending work under the agreed rule; do not erase the history.
Test the workflow before adopting it
Test a complete submission, missing attachment, unauthorized approval, duplicate action, unavailable reviewer, changed version and failed notification. For each, write the expected status, responsible person, visible message and retained record.
Useful measures include time waiting for information, time waiting for review and the share of requests returned as incomplete. Define the start and end events before calculating them. This example provides no measured business results.
Technology Solutions & Business Services