Skip to main content
Two different questions come up over an asset’s life, and this feature answers both — with a real, checkable record, not just a status field someone might forget to update.
  • “Did you receive this?” — asked once, automatically, the moment an asset is assigned to someone. This is Acknowledgment.
  • “Do you still have this?” — asked periodically, across many people or many assets at once. This is a Verification Cycle.
Both share the same underlying mechanism — a secure link, or a direct in-person check — but they’re built for genuinely different moments, and it’s worth understanding the difference before using either.

​
Acknowledgment

Assign an asset to an employee, and — if they have an email on file — they automatically receive a message asking them to confirm receipt. No setup required for this to start working; a sensible default message is used until you write your own (see Legal-grade content below). Clicking the link needs no login — the link itself is the authorization, the same principle used everywhere a secure, one-time link is involved. Confirming is recorded permanently: who, what asset, and exactly when.
If the employee has no email on file, the asset is still legitimately assigned — the acknowledgment step simply never gets sent. There’s currently no fallback notification for this case; if it’s happening often enough to matter, worth flagging so it can be surfaced more visibly.

​
Verification Cycles

Where Acknowledgment is automatic and one-to-one, a Verification Cycle is something an admin deliberately starts — “let’s confirm what everyone actually has” — and it comes in two genuinely different shapes, chosen when the cycle is created.
Each employee in scope gets one email listing everything currently assigned to them — not one email per asset. Five laptops, one email; that’s a deliberate choice, since five separate “please confirm” messages in one day reads as spam and actually discourages people from responding to something meant to hold up as a real record.They click once, confirm once, and every asset on that list is marked verified together.
No email, no employee involved at all. This is IT walking a location and checking assets off directly in the dashboard as they’re physically confirmed in person — the same action described in Physical Verification below, just tracked as part of a larger cycle instead of a one-off check.Tracking here is genuinely per-asset, not per-person — “38 of 50 assets verified,” not “12 of 20 employees confirmed.” A different question needs a different shape.
Either way, a cycle is scoped the same familiar way — everyone, a specific location, a specific department, or a hand-picked list — and runs until its deadline, until every item is confirmed (at which point it closes itself automatically), or until an admin closes or cancels it manually.

​
Tracking progress

A cycle’s status page shows completion live — the email method as a per-employee list (confirmed or not, and how many assets each covers), the physical method as a per-asset list (verified or not, and by whom). Either can be exported as a CSV at any point, not just once the cycle finishes.

​
Managing a cycle in progress

​
Physical Verification

Separate from cycles entirely, any asset can be marked physically verified at any time — an IT admin confirming, in person, right now, that an asset genuinely exists and is where it should be. No email, no employee, no waiting on anyone else. This is the same action a physical-method Verification Cycle uses internally — when done as part of a cycle, it additionally updates that cycle’s own tracking; done on its own, it simply updates the asset’s record. Either way, every asset shows when it was last physically verified and by whom, and that date is what powers the “not verified recently” filter on the Assets list.
Worth being clear about what this is not: a standalone verification is IT staff directly confirming an asset in person — a stronger claim than an employee replying “yes, I still have it” by email. If your process needs to distinguish those two levels of assurance in reporting, that distinction already exists structurally (a physical-cycle asset verification always has a verified_by person attached; an email confirmation never does) — just worth knowing they mean genuinely different things.

​
Legal-grade content

Because acknowledgment and verification can matter for audit or legal purposes — proving someone genuinely confirmed receipt of company property — the content sent isn’t just cosmetic. Admins write the actual message in a rich text editor, once per type of confirmation (assignment acknowledgment gets its own template; verification cycles get theirs), reused every time going forward. But here’s the part that matters: whatever gets sent is permanently frozen at the moment it’s sent. If you edit the template next month, every past confirmation still shows exactly the wording that person actually saw — never the current version. Editing a template only changes what happens going forward, never what already happened. This is the same principle e-signature platforms use — the exact document version at signing time is what’s preserved, not a live pointer to a document that might read differently tomorrow.
Placeholders like {{employee_name}} or {{asset_tag}} are filled in with simple, literal text substitution — never evaluated as code or logic. This is a deliberate security choice: admin-authored content merged with a real templating engine is a genuine risk if that engine can execute expressions, not just insert text. Nothing in a template can ever do more than produce the text you’d expect to see.
Every confirmation link uses the same mechanism as AssetGullak’s own account-invitation links: a random, one-time token, stored only as a cryptographic hash — never the raw value itself. The raw token exists only in the email you receive; if the database were ever compromised, nothing in it could be used to reconstruct a working link. Links expire automatically, and clicking an already-confirmed link a second time is harmless — it simply confirms nothing changed.