Approving and Working Offline in the AWRA Mobile App

The approvals hub collects every decision waiting on someone into one list: procurement requests, RFQs, quotations and purchase orders, inventory adjustments, transfers and item changes, asset movements, invoices, leave, overtime and payroll runs — and, since October 2026, finance. The finance items are expense claims, staff advances, the retirements of those advances, petty cash vouchers and payment runs. The same hub opens on the web and in the Android app, and it shows each person only the buttons their permissions allow: approve_expense_claims for claims, approve_staff_advances for advances and retirements, approve_petty_cash for vouchers and approve_payment_runs for runs.

Two of these behave differently from a simple yes or no. An expense claim has two ways to approve: Approve · repay directly, where finance pays the employee, and Approve · repay in payroll, which puts the reimbursement on this month’s pay period as a non-taxable item. Sending it back is called Return, and it asks for a comment so the employee knows what to fix. A payment run can be approved or rejected in the hub, but paying it out is never done there: executing a run stays on the payment run’s own screen, where the bank file, M-Pesa or Paystack lines are handled. Every rejection in the hub takes a reason, which is stored with the decision.

In practice: a finance manager at an NGO in Kisumu opens the hub on her phone between meetings. A field officer’s fuel claim of KES 6,400 is waiting; she taps Approve · repay in payroll, because staff reimbursements there are paid with salaries. A petty cash voucher for printer toner has no receipt attached, so she rejects it with the reason “attach the receipt”. The week’s payment run of twelve supplier bills is next; she approves it, and the accountant pays it out from the payment run screen that afternoon.

When a request is waiting on you, the push that announces it can carry Approve and Reject buttons. The server adds them only when two things are true at the moment the push is sent: the request is still pending in the approvals hub, and you hold the permission to decide it. Anyone else gets an ordinary notification that opens the record. Requests that can carry the buttons include purchase orders, requisitions, RFQs, quotations, invoices, stock transfers, adjustments, asset movements, leave requests, staff advances and payment runs. Reject opens a reply field on the notification; what you type there is the reason.

A tap does not trust the push. The app first re-reads the approvals hub and runs that item’s own action, so a request decided by a colleague in the meantime, or a permission removed since the push arrived, fails safely. The notification is then replaced with the outcome: Approved, Rejected, “Already decided, or no longer yours to decide”, or “Open the app to finish this decision”. The last one appears when the decision needs more than one tap — an expense claim, because you must choose how it is repaid — or when a reason is required and fewer than three characters were typed. On the lock screen the request shows without its details or buttons, because a decision that moves money is taken on an unlocked phone.

In practice: a procurement head in Mombasa is at the port when a purchase order for KES 480,000 of packaging is submitted. Her phone shows the push with Approve and Reject; she unlocks it, taps Approve, and the notification changes to “Approved.” Ten minutes later a stock transfer arrives that her deputy has already approved from the web; when she taps Approve, the app re-reads the hub and reports “Already decided, or no longer yours to decide”, and nothing is approved twice.

The approval PIN is for one job only: approving a discount at somebody else’s till. Every workspace has a largest discount a cashier may add on top of the item’s own discount, set under Settings › Sales and starting at 0. When a sale goes above it, the till asks for a reason and for an authority — either the cashier holds the Apply POS discount override permission, or a supervisor who holds it chooses their name and types their PIN. The PIN is never asked for in the approvals hub or on a notification; those decisions rest on your signed-in account and permissions.

A supervisor sets the PIN in the app under Profile, on the Till approval PIN card, or on the web under Settings › My Account. The card appears only for people who hold the override permission. The PIN is 4 to 8 digits, typed twice, and saving it asks for your account password, because a PIN that approves discounts is a credential of its own and a session left open on a shared till must not be able to set one. The same card removes the PIN. Five wrong entries lock it for 15 minutes; setting a new PIN unlocks it at once. A separate limit stops a cashier walking guesses round the whole team, and a supervisor can never approve a discount at their own till.

In practice: a supermarket in Eldoret caps cashier discounts at 5%. On Saturday a customer buying a damaged microwave is offered 15% off. The cashier rings it up; the till asks for a reason (“dented door, customer accepted as is”) and a supervisor. The shift supervisor, who set her PIN from her phone’s Profile on Monday, picks her name and types it. The sale records the cashier, the supervisor, the percentage and the reason, and the weekly discount review shows exactly who allowed it.

With no signal, the Android app saves work to its offline queue and sends it once, in order, when the phone reconnects. On 15 October 2026 it queues 23 kinds of work: check-ins (including receiving against a purchase order opened once while online), check-outs, stock transfers and their decisions, adjustment edits and decisions, count lines and count decisions, quality holds, asset and pooled-asset movements and their approvals, till sales, cash drops and drawer closes, approvals hub decisions, invoice approvals, leave decisions, task comments, supplier quotations — and four added in October: leave requests, new expense claims, time logged on a task, and completing a work order.

The four new ones are built to be replayed safely. Each carries an idempotency key the server remembers, so a retry after a lost response returns the first result instead of creating a second leave request, claim, time entry or completion. A new expense claim saved offline copies its receipts into the app’s own storage so they survive however long the wait; a work-order completion keeps its photos and the customer’s acceptance signature. The app is honest about timing: a leave request or claim saved offline says it has not reached an approver yet, and a queued completion leaves the work order open until it lands. Still needing a connection, and being brought offline next: editing a claim already filed, starting or cancelling a work order, ticket replies and clock-in.

In practice: a maintenance technician for a water utility in Machakos finishes a pump repair in a valley with no coverage. He completes the work order on his phone with what was done, the parts cost, two photos and the site supervisor’s signature, then files a KES 1,200 meals claim with a photo of the receipt and logs three hours against the repair task. Each shows “Saved offline”. When the van reaches the main road, the queue drains: the work order closes, the claim reaches his manager’s approvals hub, and the hours land on the task — once each, even though the first attempt timed out halfway.