How can we replace paper approvals with a digital system?
Map the current request journey, name each decision owner, and define states, permissions, exceptions and evidence. Prototype one complete workflow in the required languages, then test it with staff and realistic sample data. Include training, migration and operating responsibilities in the scope.
The key idea
Digitisation should make a request’s status and responsibility clearer. Copying a paper form onto a screen does not explain how the work will move.
Follow one request through the existing process
Use an illustrative branch-maintenance request: a staff member reports a problem, a supervisor reviews it, another team checks the requirement, and someone authorises action. Ask staff to explain what they do, not only what the procedure document says. Note messages, spreadsheets and phone calls used to fill gaps.
Record the information requested at each step and why it is needed. Identify who can return a request for clarification, who can decide, and how the applicant learns the result. Use fictional sample records in a workshop so the discussion does not expose real employee or customer information.
Describe decisions, not just buttons
A button labelled “approve” leaves important rules unexplained. Can it be used on a draft? Does approval commit a budget or only confirm that the request is complete? Can the same person submit and approve? Have the responsible department define the meaning before the developer implements the action.
Agree on states such as draft, submitted, clarification requested, under review and completed where they fit the actual process. Describe which actions move the request and what information is preserved. A correction should not silently erase the earlier submission or confuse the person waiting for an answer.
In practice · illustrative example
Test the request when its usual reviewer is absent
A request reaches its normal reviewer, who is unavailable. Staff should not need to borrow that person's account or invent an informal approval. Describe the authorised reassignment route and what the applicant sees while waiting. Include a request returned for clarification so the team can check how responsibility moves without losing its history.
Ask the process owner to review the resulting record. Can they explain who held the request, what information changed and why the final decision was made? Keep the workflow's terminology consistent in Arabic and English. The digital process should make the agreed authority easier to follow, rather than adding buttons around an unresolved paper process.
Responsibility moves with the request
-
Receive
The correct role receives the request with its current status.
-
Clarify or reassign
The authorised route handles missing information or reviewer absence.
-
Make the decision
The permitted reviewer records an understandable outcome.
-
Inspect the history
The owner can follow responsibility and the relevant changes.
Plan for the reviewer who is unavailable
Ask what happens when the assigned reviewer is on leave or a request reaches the wrong team. Define authorised reassignment and who can perform it. Set expectations for escalation through the organisation’s approved process. Do not let the software invent an approval rule that staff have never agreed to.
Use exception scenarios in the prototype: missing information, an incorrect attachment, a duplicate request, or a withdrawal after review starts. Discuss what the applicant sees and what the employee records. These cases reveal whether the system supports work or merely adds another inbox.
Check access and history with actual roles
List the information each role needs to see and change. OWASP’s authorisation guidance supports explicit access decisions and checks on requests. Ask the technical team how permissions are enforced beyond hiding a button, and how unauthorised access is tested.
Keep a meaningful history of status changes, decision reasons and responsible users according to the approved requirements. Ask who can review that history and how corrections are recorded. Test a user from another team trying to open or change the request. The test should demonstrate the agreed access rules, not assume them from the interface.
Make the result understandable in each language
Use consistent Arabic and English terms for statuses and departments. Tell applicants whether submission succeeded and what they should do next. W3C’s form guidance recommends clear success and error feedback. In a workflow, a helpful clarification identifies the missing information rather than merely saying “invalid request”.
Test with keyboard navigation and a small screen, including long Arabic names and mixed-language identifiers. Review notifications and printable documents as well as the main form. Have the department approve the wording; a translation error in a status can change what the user believes has happened.
Pilot one workflow before expanding
Choose a manageable workflow and agree on acceptance tasks. Walk through a normal request, clarification, absence cover, withdrawal and final decision with the staff who will use it. Record gaps before adding every department or importing large amounts of data.
Plan training, migration rehearsal, account administration, support and data export. Name the business owner who approves changes after launch. If a procurement process applies, follow its authorised requirements and review channels. A successful demonstration is useful evidence, but the formal acceptance process must still be agreed.
A worksheet for your team
An absence-and-clarification rehearsal
Run the test with the people who normally submit, review and supervise the request.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Reviewer absence | A request redirected through the authorised process. | Check the replacement role and applicant-visible status. |
| Missing information | A request returned with a clear clarification. | Preserve context when the applicant responds. |
| History | A record explaining actions and responsibility. | Confirm it is understandable to the process owner. |
Resolve disputed authority before building the screen. Software can display an agreed process clearly, but it cannot decide who the institution intends to authorise.
Questions for an approval-system workshop
- What does each decision mean, and who owns it?
- How are clarification, withdrawal and reassignment handled?
- Which information can each role see or change?
- What history and decision evidence must be preserved?
- Do feedback and documents mean the same thing in both languages?
- Who trains users, operates the system and approves acceptance?
Frequently asked questions
Can we begin by putting the existing paper form online?
Use the form as an input, but map what happens after submission. Review ownership, exceptions, status and access before development. Otherwise the digital form may leave staff doing the same manual handoffs.
Should every department use identical approval rules?
Use common patterns where they genuinely fit, and keep department-specific decisions explicit. The responsible organisation should approve the rules; technical convenience should not determine authority.
Does a workflow demonstration prove government-project eligibility?
It shows behaviour relevant to the demonstrated scope. Participation and acceptance requirements belong to the particular procurement and must be checked through the responsible process.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
Sources checked:
Bring one workflow into focus
Share the steps of one request and where staff lose track of it. GateGold can discuss a prototype or software scope that makes those responsibilities visible.
