Approve From the Lock Screen

It is twenty to seven on a Wednesday and the finance director is in the back of a taxi. Her phone lights up: “PR-0112 — Suppliers, week 43 needs approval.” The run pays fourteen suppliers on Thursday morning, the bank cut-off is ten, and she will not be at a desk before then. She presses and holds the notification, taps Approve, and a second later the notification changes to “Approved.” Fourteen suppliers are paid on time. Nobody had to wait for her to open a laptop.

That is the whole case for approving from the notification, and it is a strong one. The same evening, in three other organizations, the same button does something nobody intended. In one, it approves a payment run that was rejected, changed and resubmitted after the notification arrived. In another, it is pressed by a colleague who picked up an unlocked phone from a meeting-room table. In the third, it never gets pressed at all — but the lock screen it sat on showed a supplier’s name and an amount to everyone at the next desk.

Why everyone asks for the button

Approvals rarely wait on systems. They wait on people, and specifically on the gap between the moment a person learns a decision is needed and the moment they are in front of the screen where it can be taken. A requisition raised at four is approved the next morning not because anyone weighed it overnight, but because the approver read the email on the way home and had nowhere to act on it.

A mobile app closes most of that gap. A button on the notification closes the rest: no unlocking into the app, no finding the approvals screen, no waiting for a list to load on a weak connection. For routine, low-value, already-understood decisions — a stock transfer between two stores, a leave request that was discussed last week, a payment run the approver built the list for herself — that is exactly right.

The trouble is that a notification is a different kind of object from a screen. A screen is read at the moment of the decision. A notification is a photograph of a record, taken when it was sent, and it can sit on a phone for hours while the record it describes moves on. Everything that goes wrong with approval buttons follows from forgetting that.

A notification is a photograph of a record, taken when it was sent. The button on it acts on the record as it is now.

The first way it goes wrong: the stale request

The simplest version: two people can approve payment runs. Both get the notification. One approves from her laptop at six. The other sees the notification at nine and taps Approve. A naive implementation either approves it a second time, writing a second approver over the first, or fails with an error nobody can read on a lock screen.

AWRA guards this twice. When the push is sent, the server looks the record up in the approvals hub — rebuilt for that moment, not read from a cache — and attaches buttons only if the record is still pending and the person receiving the push holds the permission for its approve action. A notification about something already decided arrives as an ordinary notification with no buttons at all.

Then, when a button is pressed, the app does not trust the notification. It does not carry an endpoint to call or an action to run. It carries only the record’s key. The app asks the server for the approvals hub again, finds that record, and runs the hub’s own action for it — the same request the Approve button inside the app would send. If the record is no longer in the hub, nothing is sent, and the notification is replaced by one that says so.

The harder version is not a decision taken elsewhere but a record that changed. Here the answer depends on the document, and it is worth knowing exactly where the line falls. The key a notification carries names the record, not a version of it. The button approves the record as it stands at the moment of the press.

For a payment run that is safe in the ordinary course, because a run cannot be edited once it is submitted: changing it means returning it to draft, which takes it out of the hub, and any notification still sitting on a phone then reports “Already decided”. The edge is the run that is rejected, edited and resubmitted while an old notification is still unread. It carries the same key, it is pending again, and the old button would approve the new version, whether or not the approver has looked at the resubmitted run.

Requisitions and quotation awards governed by a value-based approval rule are protected more tightly. The rule records a fingerprint of the document — its lines, quantities and prices — when the first person signs. If the document changes, the trail is superseded and the approval starts again at step one, whichever screen or button the next signature comes from. If you rely on notification approvals for spend above a modest amount, that rule is what makes a changed document unapprovable on an old photograph of it. See the approval that needs no pad for how the signature trail itself is kept.

The second way: the phone on the desk

An approval inside an app is protected by everything between a person and the app: the phone’s lock, the app’s own sign-in, and in many organizations a biometric lock on the app itself. An approval on a notification skips the app. Whatever protects it has to be on the notification.

On iPhone, AWRA registers both buttons with the system’s authentication required flag. iOS will not run either action from a locked phone; it asks for Face ID, Touch ID or the passcode first. On Android, the app draws the notification with private lock-screen visibility: on a phone with a secure lock that hides sensitive notification content, the lock screen shows only that AWRA has a notification — no text, and no buttons. On both platforms, set up that way, the person pressing Approve has to be able to unlock the phone first.

That closes the lock screen. It does not close the unlocked phone left face-up on a table, and it is worth being plain about that. A phone that is already unlocked will run the button for whoever presses it. And if your workspace requires a biometric lock on the AWRA app, that lock is checked when the app comes to the front; a notification button does not bring the app to the front, so it is the phone’s own lock doing the work. The practical consequence is a device policy, not a software one: approvers should run a short screen auto-lock, and a phone that holds payment approval should never be the meeting room’s shared device.

The third way: the lock screen that reads out loud

Approval notifications are informative by design. A step notification from an approval rule names the document and its amount and says which step is waiting. That is what lets the director in the taxi decide without opening anything. It is also what the person beside her on the train can read.

The protection here is shared between the app and the phone, and the phone has the last word. Android’s private visibility asks the system to hide the content on a secure lock screen, and the system honours the phone’s own setting: a phone configured to show all notification content on the lock screen shows it. On iPhone, the alert text follows the phone’s Show Previews setting, which by default shows previews only when the phone is unlocked. Neither app can override a person who has chosen to show everything.

That makes two settings on the approver’s phone part of your financial control, whether anyone has written them down or not: the screen lock, and whether notification content shows on the lock screen. They belong in the same sentence of your approval policy as the approval limits.

Which decisions get buttons

A button appears only where one press is a complete decision. Where a decision has more than one approve path — an expense claim is approved either for direct repayment or for repayment through payroll — the notification carries no Approve button and tapping it opens the hub, where that choice is made on purpose. Purchase orders are approved by processing them, which is a different action from an approval, so their notifications open the order instead.

The matrix is a ceiling, not a promise. The buttons a given person sees are the ones their role allows: at the recommendation stage of a leave request the button reads Approve and records a recommendation, for those who may recommend; and someone who can view payment runs but not approve them gets an ordinary notification.

The rules behind the button still apply

Because the button sends the same request as the app, every check behind that request runs. A preparer cannot approve their own payment run while someone else in the workspace can. A requisition over its budget is still blocked where the workspace has the budget block on. A value-based rule still turns one press into one signature, and the document is only approved when the last step signs. Exposure created after the approval covers why those checks have to sit at the endpoint rather than on any particular screen.

Two things about how those outcomes are reported are worth knowing before you train people. A press that records one signature of a multi-step rule is reported on the notification as “Approved.”, because the server accepted it; the document then waits for the next step, and the next approver is notified. And when a check refuses the action, the notification says “Not sent. Open the app to try again.” rather than giving the refusal’s own reason; opening the record in the app is how to see what stopped it.

Out-of-office cover meets the button in one place. Whether a person sees buttons is decided by their permissions, not by whose turn it is in an approval rule; when a covering approver signs a step under a rule, the signature records whom they signed for, exactly as it would from the app.

1. The notification is sent

   The server rebuilds the approvals hub, finds the record, and keeps only the actions the recipient may take. One approve action and one reject action become the two buttons; anything else becomes an ordinary notification.

2. The phone draws it

   Android receives a data-only message at high priority so the app can draw the buttons itself, with private lock-screen visibility. iPhone receives an alert in the approval category, whose buttons require the phone to be unlocked.

3. The button is pressed

   The app, without opening, asks the server for the approvals hub again and finds the record by its key. A record that has gone, or an action the person may no longer take, stops here.

4. The decision is sent

   The app sends the hub’s own action for that record, with the reason if it is a reject, to the same endpoint the app uses. Every check behind that endpoint runs.

5. The notification is replaced

   The original disappears and a new one states the outcome. A decision that did not complete opens the approvals hub when tapped.

What the record keeps

The decision is recorded exactly as a decision from the app is: the approver and the time on the record, the signature on the approval trail where a rule applies, and the audit entry the record type writes. That is deliberate — an approval is an approval whichever button carried it — but it does mean the record does not say that this particular approval came from a notification rather than from the app’s approvals screen. If your auditors will ask that question, it is a short addition, and it is in the list below.

Frequently asked questions