AWRA OpsHub Search
Mobile · Approvals

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.

Android · on Google Play iPhone · native app being built

Names, amounts and the reason are illustrative. The buttons appear only when the item is pending and you hold the permission to decide it.

Only if it is yoursbuttons are attached only when the item is pending in the approvals hub and you hold the permission for its decision
Re-read firsta press re-reads the hub, so a request someone else already decided is reported as decided rather than decided twice
Unlocked phonehidden on the Android lock screen, and on iPhone each button requires authentication
The reason, in the replyReject opens the reply field; a decision that needs a reason is not sent without one
Four moments on one phone

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.

1 · Locked

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.

2 · Unlocked

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.

3 · Reject

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.

4 · Result

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.

What a notification can decide

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.

RequestOn the notification
Finance
Staff advancesApprove it, or reject it with your reason on the record.
ApproveReject
Payment runsApprove or reject the run. Paying it out stays on the run’s own screen.
ApproveReject
Expense claimsReturn it with a comment from the notification. Approving means choosing how it is repaid, so tapping the push opens the hub for that.
Approve in appReturn
Customer invoicesApprove from the notification. Cancelling an invoice is not a rejection, so it is done in the app.
ApproveCancel in app
Procurement
Procurement requestsA department’s request to buy, approved or rejected before it goes to sourcing.
ApproveReject
RFQsA request for quotation, approved before it goes out to suppliers.
ApproveReject
QuotationsA supplier’s quotation, approved or rejected.
ApproveReject
Stock and assets
Stock adjustmentsApprove or reject. Approve-and-adjust in one step stays in the app.
ApproveReject
Stock transfersA transfer between warehouses, approved before it is dispatched.
ApproveReject
Asset movementsA request to move an asset, approved before it happens.
ApproveReject
People
Leave requestsRecommend or Approve, whichever stage the request is at and you hold the permission for.
Recommend / ApproveReject

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.

ApproveA button on the notification
RejectA button that opens the reply field for the reason
In appTap the push and finish in the approvals hub
Finance in the approvals hub

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.

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.

What has to be true before a tap counts

Six checks between the notification and the record.

When it is sent

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.

When it is sent

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.

Before you press

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.

When you press

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.

When you reject

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.

Always

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.

Where it works

Android today. iPhone with the native app.

AndroidIn the app on Google Play
  • 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.
iPhone and iPadNative app being built
  • 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.

The straight answer

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.

Frequently asked questions

Which requests can I approve from a notification?
Staff advances, payment runs, procurement requests, RFQs, quotations, stock adjustments, stock transfers, asset movements and leave requests carry both Approve and Reject. Customer invoices carry Approve, and expense claims carry Return. Petty cash vouchers and advance retirements are decided in the approvals hub.
Why is there no Approve button on an expense claim notification?
Approving a claim also chooses how it is repaid — directly, or in this month’s payroll — and that is two different decisions, not one tap. The notification offers Return with a comment, and tapping it opens the approvals hub where both approve options sit side by side.
Can someone approve from my lock screen?
No. On Android an approval push is private on the lock screen, so its text and buttons appear only after the phone is unlocked. On iPhone both actions are marked as requiring authentication, so Face ID or the passcode comes first.
What happens if a colleague already decided the request?
When you press a button the app reads the approvals hub again before sending anything. If the item is no longer pending, or you no longer hold the permission, nothing is sent and the notification is replaced with “Already decided, or no longer yours to decide.”
How do I give a reason for a rejection?
Reject opens the notification’s reply field. What you type is sent as the rejection reason, under whichever field that record expects. Where a reason is required and you leave it empty or type fewer than three characters, nothing is sent and the notification asks you to finish in the app.
Can I pay a payment run from the notification?
You can approve or reject the run. Executing it — the step that moves money — stays on the payment run’s own screen, in the app or on the web, where its lines and totals are in front of you.
Does this work on iPhone?
The server already sends approval pushes to Apple devices with their own notification category, and the app’s iOS code defines the buttons for it. It reaches iPhones with the App Store release of the native app, which is being built. Until then the approvals hub works in Safari on iPhone and iPad.
Which finance items are in the approvals hub?
Expense claims, approved for direct repayment or into this month’s payroll, or returned with a comment; staff advances and their retirements; petty cash vouchers; and payment runs, approved or rejected there and executed on their own screen. They sit in the same queue as procurement, stock, asset and leave approvals, on the web and in the mobile app.

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.

Search all approved AWRA public help articles.

Open Help Center