Two Settings Decide Whether an Approval Happens
Asset movement approvals are governed by two settings that have to agree: which actions the policy covers, and which assets the policy applies to. Set one and leave the other, and the control reads as on while gating nothing at all.
The settings screen says approvals are required for high-risk assets. Whether any approval will ever happen is decided somewhere else on the same page.
Every asset movement — a check-out to a custodian, a transfer between branches, a relocation, a retirement — passes through one question before it is executed: does this need approving first? The answer is worked out in three steps, and they run in a fixed order.
-
Is this specific asset flagged?
Every asset carries its own requires-approval flag. If it is set, the movement is gated and none of the rest of this matters. This is the override for the one laptop, the company vehicle, the thing that always needs a signature.
-
Does the policy cover this action?
The workspace holds a list of which actions are subject to approval at all. If the action being performed is not on that list, the movement proceeds. This step runs before the mode is even read.
-
Does the policy apply to this asset?
Only now is the approval mode consulted. Off means no. Every movement means yes. High risk only — the default — means the asset has to match the high-risk policy.
The second step is where control quietly disappears
An empty action list means no movement is ever gated, whatever the mode says. The mode field keeps displaying "High risk only", the high-risk policy keeps being configured, and nothing is ever sent for approval — because the question of whether the policy applies to this asset is never reached. Two settings, both on the same screen, and only one of them is the one people look at.
What ships, exactly
A workspace that has never opened the asset settings screen runs on the shipped defaults. Those defaults are worth knowing precisely, because they are a coherent position rather than a set of blanks.
| Setting | Ships as | What that means on day one |
|---|---|---|
| Approval mode | High risk only | The control is on, and scoped rather than blanket. |
| Actions covered | Check-out, transfer, relocate, retire | Four of the six selectable actions. Check-in and verification are outside the policy. |
| Value threshold | Unset | No asset becomes high risk because of what it cost. |
| High-risk categories | Empty | No category is treated as high risk. |
| High-risk asset types | Empty | Physical, digital, vehicle and equipment are all treated the same. |
| Per-asset approval default | Off | A newly registered asset is not individually flagged. |
Read that table as a whole and it says something clear: out of the box, approvals are switched on, four actions are in scope, and no asset matches the high-risk policy — because none of the three things that could make one match has been set. The first approval in a new workspace happens when somebody either sets a threshold, names a category, names an asset type, or ticks the flag on an individual asset.
The control is armed. Nothing has been declared worth stopping yet.
The four ways an asset becomes high risk
When the mode is high-risk-only, an asset matches if any one of four conditions holds. Three of them are policy and are re-read on every single movement; the fourth is stored on the asset.
- Its stored risk level is high or critical. A property of the record, set when it was registered or edited since.
- Its purchase cost is at or above the value threshold. Policy — change the threshold and every asset above it is caught on its next movement, with no re-stamping needed.
- Its category is on the high-risk category list. Policy, matched case-insensitively against the categories in your own catalogue.
- Its asset type is on the high-risk type list. Policy, and the shortest route to "every vehicle needs approval to move".
The stored level is stamped once; the policy is read every time
At registration, an asset whose cost, category or type matches the policy is promoted from standard to high, and that promotion is written onto the record. Editing the asset later does not repeat it — correct a purchase cost upward and the stored level stays where it was. The reason this is a footnote rather than a headline is the third bullet above: the value threshold is evaluated live at movement time, so the corrected asset is still caught. What you lose is the label on the record, not the control.
Configuring this properly, in the order that works
You want approvals on everything that leaves the building
Mode: high risk only. Actions: check-out and transfer.
Then set a value threshold low enough to catch what you care about, or name the categories. Two settings, and the scope is legible to anybody who reads the screen later.
You want approvals on everything, full stop
Mode: every movement. Actions: all six.
This is a real position for a small register of expensive things. Be deliberate about including check-in and verification — they are the two the default leaves out, and including them means somebody approves the act of confirming an asset is where it should be.
You want approvals only on disposal
Actions: retire, on its own.
The narrowest useful configuration, and the one most organisations actually need. Retirement is the movement that ends the record; the rest are reversible.
You want no approvals at all
Mode: off — say it in the mode, not the list
Both routes produce the same behaviour and only one of them is readable. Setting the mode to off states the position; emptying the action list leaves a screen that says approvals are required and a system that never asks for one.
How to check what your workspace is actually doing
Read the two settings together, then test it. Register a throwaway asset with a cost above your threshold, check it out to somebody, and see whether it lands in the approvals queue. A control that has never been observed firing is a control nobody can vouch for — and this one has enough moving parts that reading the configuration is not the same as knowing the outcome.
Five questions to ask about asset approvals
Which actions can require approval?
A good answer sounds like
A named list.
What ours actually is
Six: check-out, check-in, transfer, relocate, verify and retire. Four of them are covered by default.
What decides whether a given asset is in scope?
A good answer sounds like
A stored level, or a policy, or both.
What ours actually is
Both. A stored risk level of high or critical, or a live match on value threshold, category or asset type.
Can one asset be gated on its own?
A good answer sounds like
Yes, per record.
What ours actually is
Yes. A per-asset flag that is checked first and overrides everything else.
What happens with the shipped defaults?
A good answer sounds like
A clear description, not "it is secure".
What ours actually is
Approvals on, four actions covered, and no asset matching until a threshold, category, type or per-asset flag is set.
How do I prove it fires?
A good answer sounds like
Perform the movement and look.
What ours actually is
Exactly that. Movements awaiting approval are counted on the asset dashboard, so a test check-out either appears there or the policy is not reaching it.
What AWRA OpsHub does today
- Three approval modes per workspace — off, high risk only, and every movement — chosen on the asset settings screen.
- A per-action policy list covering check-out, check-in, transfer, relocate, verify and retire, so approval can be scoped to the movements that matter rather than applied to all of them.
- A per-asset approval flag that is evaluated before any policy and overrides it, for the individual records that always need a signature.
- A high-risk policy matching on a value threshold, on category and on asset type, re-evaluated live at the moment of every movement rather than cached onto the record.
- Automatic promotion of a standard asset to high risk at registration when it matches the value, category or type policy.
- A count of movements awaiting approval on the asset dashboard, which is the fastest way to confirm the control is firing.
- The same policy applied to pooled quantity assets as to individually tracked ones, so a bulk movement is gated on the same terms.
More we can add to your workspace
- A warning on the settings screen when the two halves disagree — an approval mode that is on beside an action list that is empty, said plainly at the moment somebody saves it.
- Re-evaluation of the stored risk level when an asset is edited, so that correcting a purchase cost upward restamps the label on the record as well as changing what the live policy catches.
- An approval threshold expressed per action, so that a transfer between branches and a retirement can carry different bars.
- A named approver or approval route per category, rather than a single queue that everyone with the permission can act on.
- A policy simulator answering "given these settings, which of my existing assets would be gated" before the settings are saved.
- A record of when the policy itself last changed, alongside the movements it governed, so an auditor can see which rules were in force on a given date.
Where we point you to a specialist
- We will not default an approval policy to catching everything. A control that stops every movement in a warehouse on day one is a control that gets switched off in week two, and a switched-off control is worse than a scoped one. The defaults arm the mechanism and leave the scope to the organisation that has to live with it.
- Deciding what counts as high risk in your organisation is yours to set. A value threshold is a judgement about your balance sheet and your appetite, and a number we published would be arbitrary everywhere it was applied.
- Where a funder, a regulator or an insurer prescribes an approval rule for asset disposal, that rule governs and their wording beats ours. We will configure the system to match it and point you to them for what it says.
The disagreement warning is the smallest item here and removes the entire failure this article describes — one check at the point the settings are saved, comparing the mode against the action list.
Making the policy state its own effect
Everything here is already data — a mode, a list, a threshold and a per-asset flag — so the work is in showing an administrator what their configuration will do before they rely on it.
A contradiction check at save time
A mode that is on with no actions covered is flagged where somebody will see it, in the sentence they are about to confirm.
A preview of what would be gated
Given the settings on screen, the number of existing assets that would now require approval to move — before the settings are saved.
An approver route per category
Vehicles to the fleet manager, IT equipment to the technology lead, everything else to the general queue.
We publish scope, not dates.
Scope asset approvalsOur take
Splitting "which movements" from "which assets" is the right design — it is what lets an organisation gate retirements without gating every check-out, and it is why the same policy can serve a register of twelve laptops and a register of four hundred chairs. The price of that flexibility is that the control has two independent off switches and only one of them announces itself. If you configure this once and never test it, configure it in the direction that fails loudly: set the mode deliberately, name the actions deliberately, and then perform a movement you expect to be stopped. Everything in this article is legible from the settings screen once you know to read both halves of it, which is really the only claim being made here.
Check your own two settings
It takes about a minute: open asset settings, read the mode, read the action list, and confirm that between them they describe the control you think you have. If they do not, the fix is on the same screen.
Talk through asset controlsFrequently asked questions
If the approval mode is set to "every movement", does everything get approved?
Every movement whose action is on the covered list, yes. The action list is checked first and independently of the mode, so a workspace in "every movement" mode with only "retire" on the list gates retirements and nothing else. The two settings are read together, and neither one on its own describes the behaviour.
Which actions are covered by default?
Check-out, transfer, relocate and retire. Check-in and verification are the two selectable actions left out, which is a reasonable default — approving the act of receiving an asset back, or of confirming it is where it should be, adds friction to the two movements that improve your data rather than risk it.
Does raising the value threshold catch assets already in the register?
Yes, on their next movement. The threshold, the category list and the type list are all evaluated live against the asset at the moment a movement is attempted, rather than being baked into the record when it was created. Lower the threshold this morning and this afternoon's check-outs are measured against the new number.
Why does an asset's stored risk level not update when I edit it?
The automatic promotion from standard to high runs at registration only. In practice the live policy covers the same ground — an asset whose corrected cost now exceeds the threshold is still gated — so what is lost is the label on the record rather than the control over it. Restamping on edit is on the list of what a fuller version does.
Can different asset categories have different approvers?
Not today. A movement that requires approval goes to one queue, and anybody holding the permission to approve asset movements can act on it. Routing by category is a defined piece of work and is the item most often asked for alongside this one.
Do pooled assets follow the same rules?
They do. A quantity-tracked pool — four hundred chairs recorded as a pool rather than four hundred records — reads the same mode, the same action list and the same high-risk policy when units move. The approval question is asked once for the movement rather than once per unit.
