The person holding your generator does not have a login.
Most asset registers assign things to user accounts. Which quietly means the drivers, the site labourers, the contractors, the departments and the visiting auditor cannot hold anything — so the register becomes a record of what the office staff have, and the assets that actually go missing are the ones it was never able to describe. A custodian here is a person or a place in its own right, with or without an account.
A custody register built on user accounts is a register of your office.
This sounds like a modelling detail and it is the whole feature. Think about who physically holds your equipment: a driver with a vehicle, a fitter with a torque wrench, a site team with a compactor, a contractor with a generator, a department with a projector, an auditor with a borrowed laptop for a fortnight. Now count how many of them have a login to your operations system.
Custodian = user account
What happens when the register can only name logins.
Assets held by non-login staff are assigned to their supervisor, so the register says the supervisor has eleven drills. It is wrong on purpose, and everybody knows it is wrong, which is worse than it being wrong by accident.
Contractors and vendors cannot be custodians at all, so tools out with a subcontractor are either invisible or logged against whoever signed the work order.
A department cannot hold anything, so shared equipment — the meeting-room projector, the site compactor — has a fictional individual owner who leaves in eighteen months.
Creating a login for a driver so that he can appear in the register means paying for a seat, granting permissions nobody wants him to have, and running a password reset for somebody who will never sign in.
When somebody leaves, deactivating their account either orphans everything they held or blocks the deactivation. Both outcomes are bad and neither is a decision anybody wanted to make at that moment.
Custodian = its own record
What changes when a custodian is a first-class thing.
A driver, a labourer, a contractor or a whole department can hold an asset by name, with a code, a phone number and a job title — and no account, no seat and no permissions.
The link to a login is optional. Where a custodian does have an account, the two are joined so the person sees what they hold; where they do not, nothing is missing.
The link to an HR employee record is optional too and separate. A custodian can be an employee, or reference an employee number from a system that is not this one, or be neither.
A custodian carries a warehouse, a location and a department, so “who holds it” and “where is it” are answered by the same record.
Somebody leaving becomes an exited custodian rather than a deleted one, so the history of what they held stays readable — which is the whole reason you keep a register.
Six types
Because “employee” and “the maintenance department” are not the same kind of holder.
The type is not decoration. It changes what a chase looks like, what recovery means, and which report the asset belongs in. An overdue laptop with an employee is a conversation; an overdue generator with a vendor is a contract question; an item held by a department has no individual to ring at all, and knowing that in advance is the point.
Employee
employee
Your own staff. Optionally linked to an HR employee record and optionally to a login, and neither is required for them to hold something. The common case, and the one most systems handle.
Contractor
contractor
Somebody working for you who is not on your payroll. They hold real equipment, they are frequently the reason an asset is on a site at all, and in a login-based register they simply cannot exist.
Department
department
A holder with no individual. The meeting-room projector, the site compactor, the shared vehicle. Custody sits with the department, which does not leave, does not go on annual leave, and does not need a seat.
Vendor
vendor
Equipment out with a supplier — a machine away for service, a tool lent to an installer, a container with a haulier. The custody record is what turns "the supplier still has it" into a dated, named fact.
Visitor
visitor
The auditor with a borrowed laptop, the consultant with a badge and a tablet, the trainer with a projector for a week. Short-term, real, and exactly the custody nobody records.
Other
other
The honest escape hatch. Every organisation has one category the five above do not describe, and forcing it into "employee" corrupts the register more than admitting it does not fit.
Four statuses, and one of them is the interesting one
Deleting the person who left destroys the only record of what they had.
This is the most common way a custody register dies. Somebody leaves, an administrator tidies up, and eleven months of custody history becomes a set of movements pointing at a name that is no longer there. The fix is not clever — it is a status.
Status
What it means operationally
active
Available to receive custody. The default, and the only status from which a new handover can be made.
inactive
A holder who is not currently in the rotation — seconded elsewhere, on extended leave, a department stood down. Not available for new handovers, but everything they still hold remains theirs and remains visible. The distinction from "exited" matters because inactive is reversible.
suspended
Custody withheld deliberately. Somebody under investigation, a contractor mid-dispute, a vendor whose account is on hold. The status is the record of a decision rather than an administrative state, which is why it is separate from inactive.
exited
Gone, and kept. The person has left, the contract has ended, the department has been dissolved. They can receive nothing further, and every movement they were ever part of still names them and still reads correctly. This is what a deletion would have destroyed, and it is why the register can answer questions about people who no longer work for you.
And where a custodian record genuinely has to go, it goes to the recovery centre rather than out of existence — with a ninety-day retention default and a permanent delete that is refused while custody, movement or pooled balance history still points at it. That is the same discipline applied one layer down: the register is only worth having if its history cannot quietly evaporate.
What a custodian record carries
Enough to find the person, and enough to find them again in two years.
A custody register is used twice: today, to ring somebody about a missing drill, and eventually, to answer a question about a handover from a year ago. The fields are chosen for both.
Custodian codeThe stable identifier you choose — CTR-0114, EMP-001. Referenced by the asset import template, printed on handover notes, and the thing that survives a name change or a marriage.
NameThe one required field alongside the type. Everything else is optional, because a register that refuses a record until eleven fields are filled is a register nobody keeps up to date.
Custodian typeOne of the six. Required, because it changes what a chase looks like.
StatusActive, inactive, suspended or exited — availability and history in one field.
Email & phoneHow you reach them. The phone number matters more than the email for exactly the custodians a login-based register cannot hold.
Employee numberA reference into your HR system or payroll, whether or not that system is this one. Useful precisely when the two are separate.
Job titleContext for whoever reads the record later and does not know the person.
DepartmentWhich part of the organisation this custody belongs to, for cost attribution and for reporting by team.
WarehouseThe site or store they are attached to, so custody and location are answered together.
LocationThe finer position within the site, where you use one.
External referenceAn identifier from another system — a contract number, a supplier code, a badge number — kept as itself rather than crammed into the notes.
NotesThe sentence that explains the record. "Seconded to the Kisumu depot until March" is worth more than four structured fields.
Plus two optional links that are deliberately separate from each other: a linked user, so a custodian who does have an account can see what they hold, and a linked employee, so a custodian who is on the HR register is joined to it. Neither is required, and neither implies the other — a contractor can have a login without being an employee, and an employee can be a custodian without ever signing in.
How custody actually moves
Nine movement actions, each with its own permission, because these are not the same decision.
Handing a laptop to somebody, moving a compactor between sites, and declaring a generator stolen are three completely different acts with three different consequences and three different people who should be allowed to do them. So they are nine separate actions with nine separate permissions rather than one “update asset” that covers everything.
Check out
Custody passes to a named custodian, with the condition recorded, photographs where you want them, and an expected return date so the asset can become overdue rather than merely absent.
checkout_assets
Check in
It comes back. Condition is recorded again at this end, which is what makes damage attributable to a period of custody rather than to nobody.
checkin_assets
Transfer
Custody moves from one holder to another without passing through the store. The record names both ends, which is the only way a three-way dispute has two named parties in it.
transfer_assets
Relocate
The asset moves between warehouses or locations without changing who is responsible for it. Kept distinct from transfer on purpose: place and person are different facts.
relocate_assets
Verify
Somebody has physically laid eyes on it and confirms it is where the system says. This is the movement that turns a register into a verified register, and it is the one most often skipped.
move_assets
Mark damaged
A condition change with consequences — it affects availability, and it belongs to whoever held it at the time. A separate permission, because reporting damage and authorising a write-off are different jobs.
mark_assets_damaged
Mark lost
The honest action. Recording that something cannot be found, when and by whom, is worth far more than leaving it showing as available forever. It also raises a risk notification.
mark_assets_lost
Retire
End of life. The asset leaves service with a record of when and who decided, rather than quietly disappearing from a list.
retire_assets
Adjust
For pooled assets: correcting a quantity that has drifted, as an explicit adjustment with a reason rather than an edit to a number.
edit_assets
Every movement additionally records what a dispute would need: the custodian it left and the custodian it reached, the department, warehouse and location at both ends, the condition before and after, who performed it, when it occurred, and where it came from — a manual entry, a barcode scan, a QR scan, the mobile app, an import or the API. Where you require it, a GPS position with its accuracy and the moment it was taken can be captured too, and required for checkout, check-in, transfer or verification independently.
When a handover needs a second person
Approving every handover is how an approval control gets switched off.
A policy that requires a manager's approval to lend a stapler will be abandoned within a month, and then the generator goes out unapproved too. So there are three modes, the default is the middle one, and which actions it covers is your decision rather than ours.
none
Nothing is held
Movements complete as they are recorded. Appropriate for a small team where the person recording the movement is the person accountable for it, and where an approval step would only add delay.
high_risk_only
Only what you class as risky
The shipped default. A movement is held for approval when the asset itself is flagged as requiring approval, or when it matches your high-risk policy — a value above a threshold you set, a category on your list, or an asset type on your list. Everything else completes immediately.
all_movements
Every covered action
For environments where custody is genuinely controlled — regulated equipment, donor-funded assets under a grant condition, anything where the audit expects a second name on every handover.
And separately, which actions the mode applies to. Out of the box it covers check-out, transfer, relocate and retire — the four that change who is responsible or take an asset out of service. Check-in is deliberately not on that list: making somebody wait for approval to return equipment is how assets end up staying in a van. You can add it, and you can remove any of the four, and an asset can additionally be flagged individually as requiring approval regardless of the mode.
A held movement is genuinely held: the pooled balance does not move and the asset's state does not change until somebody with the approving permission decides. Rejecting records the reason. And approving is a different permission from recording — signing a handover is part of recording it, not part of approving it, which is why the signature route is gated on movement rather than on approval.
The straight answer
What a custody record proves, and what it does not.
Custody is an operational control with real evidential weight and it is not a legal instrument. Being clear about which is which is worth more to you than a stronger claim would be.
The rest of the register
Custody is one axis. Quantity, condition and evidence are the others.
“Who has the generator?” becomes a lookup rather than a group message.
And when the answer is a contractor who finished a fortnight ago, you have his phone number, the date he signed for it, the condition it was in and a photograph. That is a short conversation instead of a written-off asset.
Drivers, labourers, contractors and departments can hold things, so the register stops being a record of the office.
No seats for people who never sign in
A custodian needs a name and a type. A login is optional and costs you nothing when it is absent.
History survives staff turnover
Exited rather than deleted, so what somebody held two years ago is still answerable.
Overdue is a state, not a feeling
An expected return date turns absent equipment into a dated, chaseable exception.
Damage has a period and a holder
Condition recorded at both ends of every handover, so a dent belongs to a custody rather than to nobody.
Approval where it earns its place
High-risk only by default, four covered actions, check-in excluded, and a per-asset override.
'What happens to custody history when somebody leaves?', 'a' => 'They become an exited custodian rather than a deleted record. They can receive nothing further, and every movement they were ever part of still names them and still reads correctly. This is the most common way a custody register dies — an administrator tidies up after a leaver and eleven months of history becomes movements pointing at a name that is no longer there. There are four statuses in all: active, inactive (temporarily out of the rotation but still holding what they hold), suspended (custody withheld as a decision, for an investigation or a dispute) and exited. Where a custodian record genuinely has to go it goes to the recovery centre, with a ninety-day retention default and permanent delete refused while custody or movement history still references it.'], ['q' => 'What does a handover record?', 'a' => 'Both ends and the condition at each. Specifically: the custodian, department, warehouse and location it left and the ones it reached, the condition before and after, who performed it, when it occurred, and the source it came from — manual entry, a barcode scan, a QR scan, the mobile app, an import or the API. An expected return date can be set so the asset becomes overdue rather than merely absent, with a configurable reminder lead time. Photographs can be attached, served through a permission-gated route rather than a public URL. Where you require it, a GPS position with its accuracy and capture time is recorded too, and can be made mandatory for checkout, check-in, transfer and verification independently of each other.'], ['q' => 'How many movement actions are there, and are they separately controlled?', 'a' => 'Nine, each with its own permission: check out, check in, transfer, relocate, verify, mark damaged, mark lost, retire and adjust. They are separate rather than one "update asset" permission because they are genuinely different decisions — handing somebody a laptop, moving a compactor between sites and declaring a generator stolen have three different consequences and three different sets of people who should be allowed to do them. Relocate is deliberately distinct from transfer: place and person are different facts, and an asset can change site without changing who is responsible for it.'], ['q' => 'Does every handover need approval?', 'a' => 'That is your choice, and the default is deliberately not "yes". There are three modes: none, high-risk only, and all movements. High-risk only is the shipped default — a movement is held when the asset is individually flagged as requiring approval, or when it matches your high-risk policy by value threshold, category or asset type. You also choose which actions the mode applies to; out of the box it covers check-out, transfer, relocate and retire, the four that change responsibility or take an asset out of service. Check-in is deliberately excluded, because making somebody wait for permission to return equipment is how equipment stays in a van. A policy requiring approval to lend a stapler gets abandoned within a month, and then the generator goes out unapproved too.'], ['q' => 'Is a held movement really held?', 'a' => 'Yes. Nothing moves while a movement is pending: the pooled balance does not change and the asset\'s state does not change until somebody holding the approving permission decides. A rejection records its reason. Approving is a different permission from recording, and signing is deliberately part of recording rather than part of approving — the signature route is gated on the movement permission, because the person taking the mark at the gate is not the person authorising the handover from an office.'], ['q' => 'Can a signature on a handover be used as legal proof?', 'a' => 'It is strong operational evidence and a weak legal instrument, and those are different things. What you get is a mark taken from somebody physically present, with their printed name and the moment recorded, locked once the record is decided, working with no network connection and riding the offline queue. What you do not get is a cryptographic digital signature, a certificate, or any eIDAS, ESIGN or UETA claim — and you should not accept one from us. In practice most custody disputes are settled by showing a person their own mark and the date, which is the job this does well.'], ]" />
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.
We use necessary cookies for secure sessions. With your permission, we also use cookies and browser storage for preferences, analytics, and demo engagement. Privacy Policy
AWRA OpsHub
Cookie settings
Cookie Consent Manager
Necessary cookies stay on for login, CSRF protection, and security. You can choose the optional categories below.
Overview
General Information
AWRA uses cookies and browser storage to keep public pages secure, remember selected preferences, measure website performance, and manage demo engagement prompts.
You can choose whether functional and marketing engagement storage apply. Analytics measurement is always active in this AWRA setup.
These settings apply to AWRA public website experiences such as the homepage, feature pages, pricing calculator, blog, help center, and request-demo page. Authenticated dashboard and vendor portal sessions still rely on required security cookies.
Required
Always active
Functional
Optional
Analytics
Always active
Marketing
Optional
For more context on privacy handling, open the Privacy Policy.
Required Cookies
Required Cookies
Always Active
Required cookies and storage support basic website delivery, secure sessions, request protection, and remembering the consent choice itself.
These cannot be switched off from this manager because disabling them would break login/session behavior, form protection, or the ability to remember the privacy choice you save.
Cookie details
Session security: keeps secure server sessions working while browsing AWRA.
CSRF protection: helps verify form submissions and protect requests.
Consent record: stores the preference decision so the banner does not keep asking after a choice is saved.
Examples: Laravel session cookies, CSRF tokens, and the AWRA consent preference record.
Duration: session security can expire with the browser/session; saved consent can last longer so the same browser remembers the choice.
Functional Cookies
Functional Cookies
Functional storage improves the public website experience by remembering interface choices, helper states, dismissed notices, and short-lived interaction preferences.
Turning this off does not stop secure required cookies or analytics. It only limits optional convenience memory.
If disabled, AWRA may show some helper prompts again or forget non-essential display choices. Core public pages, contact forms, and request-demo forms still work.
Cookie details
UI preferences: remembered display choices and helper states where available.
Dismissed notices: session-level or preference-level memory for notices the visitor has closed.
Frequency helpers: optional browser storage that prevents repeated prompts when allowed.
Examples: localStorage or sessionStorage values for dismissed banners, guide/helper states, and lightweight public-page preferences.
Effect when off: AWRA avoids optional convenience memory unless it is also allowed through marketing and engagement preferences.
Analytics Cookies
Analytics Cookies
Always Active
Analytics helps AWRA understand public page performance, traffic patterns, and content usefulness so we can improve the marketing website.
This category does not by itself enable demo popups, exit-intent prompts, or advertising pixels. Those are controlled by Marketing & engagement.
In this AWRA setup, Google Analytics and Google Tag Manager measurement are treated as mandatory website measurement and remain active.
Cookie details
Google Analytics / GTM: measures aggregate traffic and page activity.
Performance insight: helps identify which public pages, docs, and demo paths visitors use.
Operational signal: supports website quality decisions without enabling demo popups by itself.
Examples: Google measurement identifiers such as GA/GTM tags and related browser identifiers set by Google scripts.
Use: page views, source/referrer trends, public content performance, and product education page effectiveness.
Marketing & engagement
Marketing & engagement
Marketing and engagement storage supports demo prompts, exit-intent prompts, campaign attribution, and future advertising pixels.
When disabled, AWRA will not auto-open demo or exit-intent popups. CTA buttons can still open a form because that is a direct visitor action.
When enabled, AWRA can remember that a visitor already saw, dismissed, or submitted a demo prompt so the same popup is not repeated aggressively.
Cookie details
Demo prompt memory: tracks whether an auto prompt or exit prompt was recently dismissed.
Demo submission memory: avoids asking again after a visitor submits a demo request.
Campaign context: keeps source page, referrer, and UTM context available for demo requests.
Examples: popup frequency caps, demo-submitted flags, engagement source fields, and UTM/referrer context.
Effect when off: auto demo prompts and exit-intent prompts stay blocked; normal navigation and manually clicked CTA buttons still work.