Assets

The Assets module tracks every piece of company equipment — laptops, phones, badges, anything worth keeping tabs on — from the day it's purchased through however many employees it's handed to, and its eventual retirement. It's typically used by HR or IT administrators, with employees able to request and return equipment themselves.

This guide gives the big picture: what the module is for, how an asset flows through it end to end, who sees what, and what can be customized. Deeper guides for each area are linked below. No technical background needed.

Purpose

Assets answers a simple pair of questions: "Who has this right now, and what's its condition and history?"

Instead of tracking equipment in spreadsheets, everything lives in one place:

• Every physical asset, individually tracked by its own ID, purchase details, and current status.
• Optional categories and batches to keep related assets organized (all the laptops, or everything bought on one purchase order).
• Self-service requests, so employees can ask for what they need instead of emailing IT.
• A full handover and return history, with condition notes and photos at each end.

What's Included

Assets is made up of a few connected areas, each covered in its own guide:

Area	What it covers
Categories & Assets	Setting up categories and batches, and adding individual assets with tracking IDs, purchase details, and expiry alerts.
Requests, Allocation & Returns	Employees requesting equipment, approvals, direct allocation, returns, damage reports, and the full history log.
Asset Dashboard	The module's own at-a-glance view of what's in use, available, and pending — see below.

The Asset Lifecycle

A typical asset moves through the module like this:

1. It's added to inventory. HR records the asset under a category, with a unique tracking ID, purchase date and cost, and optionally groups it into a batch (useful for equipment bought together) and sets an expiry date for automatic alerts.
2. It gets requested — or handed out directly. An employee can request an asset by category (not a specific unit — the exact one is chosen at approval time), or HR can skip the request step entirely and allocate a specific available asset straight to someone.
3. It's approved and handed over. HR picks an available asset from the requested category, marks it in use, and the employee is notified. The handover condition can be documented with photos.
4. It's used, and occasionally flagged. While an asset is checked out, whoever's holding it — or anyone with edit rights — can file a free-text report if something's wrong with it, independent of returning it.
5. It's returned. The employee flags it for return; HR then processes the actual return, records its condition (healthy, minor damage, or major damage) with photos, and the asset either goes back into the available pool or is marked unavailable if it came back damaged.
6. The full trail stays on file. Every allocation and return is kept in a running history log, searchable by asset or by employee.

What Each User Sees

Assets area	Employee	Reporting Manager	HR Administrator
Request an asset for themselves	✅	✅	✅
Request an asset on someone else's behalf	—	—	✅
View their own requests & allocations	✅	✅ (+ their team's)	✅ (everyone's)
Approve or reject a request	—	—	✅
Allocate an asset directly (no request)	—	—	✅
Flag their own asset for return	✅	✅	✅
Process a return	—	—	✅
File an issue / damage report	✅ (assets they hold)	✅ (assets they hold)	✅ (any asset)
Add categories, batches & assets to inventory	—	—	✅
Asset Dashboard & history	—	—	✅

In short:

• Employees can request and return equipment for themselves, and report a problem with whatever they're currently holding — but can't approve requests or manage inventory.
• Reporting Managers additionally see their team's requests and allocations alongside their own, without needing any special permission — the same manager-hierarchy visibility used across the rest of the system (see User Roles & Access). Seeing a request isn't the same as approving it, though — approval requires the administrator permission regardless of reporting line.
• HR Administrators manage inventory, approve and allocate, process returns, and see everything.

How Visibility Is Decided

1. Permissions. Adding inventory, approving or allocating, and processing returns all require the specific permission for that action — being someone's manager doesn't unlock these on its own.
2. Ownership. An employee can always request, view, and return their own assets, and report an issue on whatever they currently hold, without needing any permission.
3. The reporting line. Without the broader "view all requests" permission, the combined requests-and-allocations list falls back to showing a manager their own requests plus their subordinates' — the standard manager-hierarchy visibility used elsewhere in the system, not a dedicated "asset manager" role.
4. Company. In a multi-company setup, assets, requests, and allocations are scoped to the company currently selected. Categories are the exception — a single category can be shared across multiple companies rather than belonging to just one.

Customization Options

• Categories and batches are entirely up to the company — as granular or broad as needed.
• Expiry alerts are optional per asset — set an expiry date and how many days ahead to be notified, or leave it blank for assets that don't expire.
• Condition photos can be attached at both handover and return, for a visual record alongside the written condition notes.

Asset Dashboard

Alongside the request-and-allocation workspace, Assets has its own at-a-glance view. It shows:

• Totals — how many assets exist company-wide, how many are currently in use, and how many requests are pending.
• A status breakdown chart — assets split by In Use, Available, and Not-Available.
• A by-category chart — how many assets in each category are currently in use.

Access requires the administrator permission for viewing asset categories — it isn't available to employees or reporting managers, even for their own team's equipment.

Good to Know

• Every physical unit is tracked individually. There's no "quantity" field — fifty identical laptops are fifty separate asset records, each with its own tracking ID, optionally grouped under one batch for convenience.
• A request is for a category, not a specific unit. The exact asset handed over is chosen by HR at approval time, from whatever's currently available in that category.
• A damaged asset doesn't get a separate "damaged" status. Returning something as minor or major damage sets it to Not-Available, the same status used for anything else pulled out of the available pool — the damage detail itself lives in the return record's condition notes and photos.
• Deleting an asset is blocked if it's currently in use or has ever been allocated to anyone — its history is protected rather than lost.
• Offboarding checks in on unreturned equipment. The Offboarding dashboard surfaces any assets still checked out to someone in the exit process, with a one-click reminder email — though it's a visibility nudge for HR, not something that blocks offboarding from completing.

Every asset, always accounted for.