The Approvals Inbox
When a sale needs more authority than the associate has, the associate asks for an approval, and it waits in your Approvals inbox until a manager decides it. You can decide from your own phone, wherever you are in the store, or in person at the till beside the associate. This page covers both routes, and what an approval does and does not authorize once you have given it.
Prerequisites
- You have the right to decide approvals. It comes with the manager role that ships with iVendNext, and an administrator can also grant it in iVendNext Desk. See Granting Permissions.
- You are assigned to the store the request was raised at. A request reaches only the managers of that store, and never a wider group.
- Your phone has a live connection and is the active enrolled device. An approval cannot be raised or decided while the phone is offline, and every manager read is refused from a phone that has been superseded or retired.
What an associate can ask you to approve
There are five requests an associate can raise. Each one becomes an ask only when the associate cannot do the thing themselves.
| What the associate is trying to do | When it becomes an ask |
|---|---|
| Discount one line | The discount is larger than that associate's own percentage cap |
| Discount the whole sale | The discounts on the sale together pass the store's cumulative limit |
| Type a price by hand | The price is outside the window that associate is allowed to move within |
| Void a line | Voiding is beyond that associate's authority |
| Take a return with no original receipt | Always, unless that associate has been granted the right to do it themselves |
The app refuses to escalate anything the associate could simply do. Inside their own cap, it tells them to apply the discount themselves. Inside the store's cumulative limit, it tells them no approval is needed. If they already have the right to void, or to take a receipt-less return, it tells them to do it directly. The ladder exists so that a manager is asked only when a manager is genuinely required.
Deciding from your own phone
Your phone carries a queue of the requests waiting at the store you are assigned to, oldest first. Each one shows who asked, what for, on which line and for how much, how long it has been waiting, and how long it has left before it lapses. When you open a request, you can approve it or decline it.
- A decline needs a reason. It will not save without one, and the associate is shown it. A refusal with no reason only sends the associate back to you.
- You cannot decide your own request. If you raised it, you cannot approve it by any route, including in person at the till. The check matches on who asked, not on who happens to be signed in, and it matches whatever the capitalization of a sign-in, so it cannot be sidestepped by spelling a name differently.
- Two managers deciding at once is a handled state, not a race. The second one gets the first one's outcome back, unchanged. Nothing is overwritten, and no request is decided twice.
- A request nobody answers lapses on its own. Nobody waits without end. The waiting count on your home screen, your queue, and the associate's own screen all agree about what is still pending.
Deciding in person, at the till
When you are standing beside the associate, there is no reason to wait for a notification. You sign off on the associate's own phone.
- The associate raises the request as usual.
- You enter your own sign-in and password on the associate's phone.
- The app checks three things: that the credential is correct, that the account is enabled, and that you actually have the right to decide.
- The decision is recorded against you, marked as taken in person, and applies exactly as a remote one would.
Three things about this route are worth knowing, because each is deliberate.
- All three failures give the same answer. A wrong password, a disabled account, and a manager who does not have the deciding right are refused identically. A wrong answer never tells anyone which part was wrong, so the phone cannot be used to work out who has authority.
- Repeated wrong credentials are throttled. The app counts failed attempts against the same approver within a rolling window, and stops answering after a small number of them. It clears with time.
- A wrong password here does not sign the associate out. The credential being checked is yours, not the session's, so a wrong answer does not drop the associate's session and their basket with it.
A remote decision and an in-person one are told apart afterward. Every decision records who decided, when, and by which route. That distinction is usually the first thing an auditor asks about.
What an approval authorizes
An approval is a bound, single-use authorization of one exact thing. It is not a mode you switch on for the shift. It is bound to several facts at once, and if any of them does not match when the approval is used, the app refuses rather than authorizing the wrong thing.
| Bound to | So this is refused |
|---|---|
| The sale it was raised for | The approval applies to that sale alone. It cannot carry to another sale, or to the next customer's basket |
| The store it was raised at | An approval raised at one store is refused at another |
| Its kind | A discount approval will not authorize a hand-typed price, and a void approval will not authorize a return |
| The person who asked | Someone else's approval will not work on your sale |
| The item | An approval for one item will not price a different one |
| The amount it was granted against | If the amount moved, the approval stops authorizing |
| One use | It is spent by the sale that completes with it. It cannot price a second line, cover a second void, or authorize a second return |
The bind to the sale is the one to understand first. An approved discount or hand-typed price applies only to the sale it was raised for. If that sale has already ended by the time the decision comes through, the approval applies nothing, and the app tells you so. A grant given for one customer can never apply to the next customer's basket.
When an approval stops working
- The basket moved after you saw it. If a quantity was edited, another line was added that changes the sale total, or a promotion recalculated, the approval stops authorizing and hands the current figure back to be asked for again. The app will never apply an approval to a number nobody approved. The remedy is always the same: ask again at the current amount.
- A pending request lapses. If nobody answers it in time, the line keeps the price it already had, and the request can be raised again.
- An approved but unused approval lapses too. An approval granted and then left sitting is not a standing permission. How long a request waits for an answer, and how long a granted approval stays valid, are store settings your implementation team sets with you.
- Once a request has been decided, it cannot be edited. Not the decision, and not the facts it was granted against, which are fixed from the moment the request is created. Where a change is needed, the answer is a new request rather than an amended one.
A note for administrators
An approval can also be moved to approved in iVendNext Desk directly. That route is the Desk's own, and it does not apply the phone's self-approval bar, because the Desk authorizes a signed-in manager's own action the same way. If your policy depends on the self-approval bar, keep the decision on the phone.
When the connection drops
While the phone has no connection, no approval can be raised and none can be decided in the app. Both are actions on the server. Asking for an over-cap discount names the connection as its reason, and the inbox freezes rather than showing a stale queue. There is no offline route for an in-person decision either.
A sale composed while the phone was offline can still be authorized once the phone reconnects and the held sales are worked through, by a manager present with their own credentials. That is a reconnect behavior, not an offline one, and it needs the same deciding right that both online routes require. What else does and does not survive an outage is covered in Working Offline.