Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Approve or reject from the notification. Unlock first, and the reason goes in the reply.
When a request is waiting on you, the push that tells you so carries Approve and Reject buttons. Reject asks for its reason in the notification’s reply field. The phone has to be unlocked before either counts, and the app checks the item is still pending and still yours to decide before it sends anything.
Names, amounts and the reason are illustrative. The buttons appear only when the item is pending and you hold the permission to decide it.
From a buzz in your pocket to a decision on the record.
The same staff advance, from the moment the push lands to the moment the notification reports what happened. Nothing here opens the app unless the decision needs more than the notification can carry.
The lock screen shows that it came, not what it says
On Android an approval push is marked private, so the lock screen shows the app and nothing of the request or its buttons. Anyone holding the phone sees that something is waiting, and no more.
The request, with its two buttons
Once you are in, the notification shows the request and the buttons the server allowed. On iPhone the buttons sit on every notification of this kind, and each one asks for Face ID or the passcode before it acts.
The reason is typed where you are
Reject opens the notification’s reply field. What you type travels as the rejection reason, under whichever field that record’s own reject action reads. Where a reason is required, an empty or two-letter one is not sent: the notification asks you to finish in the app.
The notification says what happened
The original is replaced with the outcome: approved, rejected, already decided by someone else, or not sent — in which case tapping it opens the approvals hub so you can try again.
Eleven kinds of request, and the buttons each one gets.
A button appears only where the decision is a single tap. Where the approvals hub offers more than one way to approve — or the other choice is something other than a rejection — that half opens in the app instead.
Why some decisions open the app
A push never carries a decision of its own. It carries the approvals hub’s key for the item and the buttons you may use. When you press one, the app reads the hub again and runs that item’s own action — the same request the hub screen would send.
So a decision the hub offers in two flavours, like an expense claim repaid directly or in this month’s payroll, cannot be one button. Rather than guess, the notification leaves that half to the app.
Your permissions count at both ends: when the push is sent, and again when you press.
Claims, advances, petty cash and payment runs, in the same queue as everything else.
The approvals hub is the one list of everything waiting on a decision, on the web and in the mobile app. It holds the finance items alongside procurement, stock, assets, leave and the rest, so an approver works one queue rather than five screens.
Client visit, Eldoret · KES 8,650.00
Receipts and change for 20,000.00 · 1,350.00 returned
Padlocks for the yard gate · 2,400.00 · Main office float
Pay on 30 Oct 2026 · 1,284,500.00
Expense claims
Approve and repay it directly, or approve it into this month’s payroll so it lands on the payslip. Return it with a comment when it needs another look.
Staff advances and their retirements
Approve or reject the advance itself, and later the retirement that accounts for it — the receipts and the change handed back.
Petty cash vouchers
A voucher against a float, approved or rejected with a reason, from the same queue.
Payment runs
Approve or reject a run. Executing it — the step that moves money — stays on the run’s own screen, where its lines and totals are in front of you.
Six checks between the notification and the record.
Pending, in the hub, right now
The server rebuilds the approvals hub as it sends the push, and attaches buttons only if the record is in it — so a request that was decided in the moment before the push left goes out as a plain notification.
Yours to decide
Each button is checked against the recipient’s own permissions. Someone who is told about a request but cannot decide it gets the notification without buttons.
An unlocked phone
Android keeps an approval push private on the lock screen, so its text and buttons appear only once the phone is unlocked. iPhone marks both actions as requiring authentication.
The hub is read again
The app fetches a fresh hub and looks for the item. If a colleague decided it while the notification sat there, or your permission has since been removed, nothing is sent and the notification says so.
A real reason
Where the record requires a reason, fewer than three characters in the reply field is not sent; the notification asks you to finish in the app instead.
The hub’s own action
The press runs exactly the action the approvals hub lists for that item, through the same API the hub screen uses. A notification can never offer a decision the hub would not.
Android today. iPhone with the native app.
- An approval push arrives at high priority as data, and the app draws it with its buttons — so it can attach the reply field and the private lock-screen setting itself.
- Approve, Reject with a reply field, and the result shown in place of the original notification.
- Tapping the result after a failure, or a push whose decision needs the app, opens the approvals hub.
- See the Android app for everything else it does.
- The server already sends approval pushes to Apple devices under their own notification category, with the alert text and the buttons that category defines.
- The app’s iOS code registers that category: Approve, and Reject as a destructive action with a text field for the reason, both requiring authentication.
- It reaches iPhones with the App Store release of the native app, which is being built. Until then the whole approvals hub works in Safari.
- Progress and what is left: AWRA on iPhone and iPad.
What AWRA OpsHub does today
- Approve and Reject buttons on the push for staff advances, payment runs, procurement requests, RFQs, quotations, stock adjustments, stock transfers, asset movements and leave requests, with Approve alone on customer invoices and Return alone on expense claims.
- Buttons only when the item is pending and the recipient may decide it, checked by the server against a freshly rebuilt approvals hub as the push is sent.
- A fresh read of the hub on every press, so a decision taken elsewhere is reported as already decided rather than sent again.
- The reject reason from the notification’s reply field, sent under the field each record’s reject action reads, and held back when a required reason is too short.
- Private on the Android lock screen, and authentication required for both actions on iOS.
- The outcome in place of the notification — approved, rejected, already decided, or not sent with a tap through to the hub.
- Expense claims in the approvals hub, approved for direct repayment or into this month’s payroll, or returned with a comment.
- Staff advances, advance retirements, petty cash vouchers and payment runs in the approvals hub, on the web and in the mobile app, with payment-run execution kept on the run’s own screen.
More we can add to your workspace
- Approve buttons on expense-claim notifications, using a repayment method your organization sets as its default so the choice can be one tap.
- Push buttons for petty cash vouchers and advance retirements, which are decided in the approvals hub today.
- Push buttons for purchase orders and payroll runs, alongside the eleven kinds of request that carry them now.
- Decisions from a notification queued while offline, replayed when the phone reconnects the way in-app approvals already are.
- The native iPhone app on the App Store, being built from the same code, with the approval category already written.
Where we point you to a specialist
- We do not pay out a payment run from a notification. Approving releases the run; executing it happens on its own screen, where the lines, the totals and the bank account are in front of you.
- We do not show a decision on a locked phone. A request that moves money is decided on a phone its owner has unlocked, and that stays true whatever else is added here.
If your approvers live on their phones, tell us which requests they wait on most and how your organization repays expense claims. We will come back with a written spec, a timeline and a price for putting those decisions on the notification too.
Where the requests come from, and where else you decide them.
Frequently asked questions
Which requests can I approve from a notification?
Why is there no Approve button on an expense claim notification?
Can someone approve from my lock screen?
What happens if a colleague already decided the request?
How do I give a reason for a rejection?
Can I pay a payment run from the notification?
Does this work on iPhone?
Which finance items are in the approvals hub?
Help Center
Need a quick answer while you read?
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.