How assets works

One register of devices. Each device has a tag (the sticker), a serial, vendor, model and kind; a status; the person who has it; and an append-only history — every hand-over, return, sale, scrapping, note and photo, with who did it and when.

The intake

The moment a device changes hands is the only moment the information exists. So the intake starts with the camera: photograph the back or the sticker. If an owner set an AI key in the hub (Settings → AI) and granted this app the AI lane, the picture is read — every code on it, with a confidence. Readings are only suggestions: the register matches them against tags and serials (exact, then with 0/O · 1/I · 5/S · 8/B folded, then by one or two edits) and shows candidates; you confirm. Nothing matches? Two taps create the device with what was read. Then you say what happened; the photo is kept as evidence on that event.

Without an AI key the camera still works: the photo is stored, you search by tag or serial (the same fuzzy matching), or add the device by hand. Only the reading step is off, and it says so with a link to the hub's settings.

People

People come from the hub directory. A hand-over picks the person there — no free-text names — so offboarding in the hub can list the devices a person holds and reassign them. The person is told through the hub's notifications.

Roles

Hub owners, admins and helpdesk run the register; so do members of the admins group and the named admins. Everyone else in the directory sees the devices assigned to them.

Photos

Scaled on the phone to at most 1280 px before upload, stored in the app itself, shown in the history. 900 KB per photo, twelve per device, 400 MB in total. When AI reading is enabled, the AI vendor receives the picture. Names, faces or other personal details visible in the image are included; check the image before sending it.

Device management

Connect Iru (formerly Kandji), Jamf Pro or Microsoft Intune under Settings. Every six hours — or when you press Sync now — the register pulls what the MDM knows: serial, model, OS, last check-in, the logged-in user. A device the register does not know is created (assigned to the MDM's user if that person is in the hub directory, otherwise in stock with the name noted). A known device gets its gaps filled. Where the register says one person and the MDM another — or the register says sold, scrapped or lost and the MDM still sees the device — nothing is changed; a mismatch is shown on the device and in the list, for a human to settle. Secrets never leave the app except towards the MDM; the calls go out from your engine as single-node requests.

Apple Business Manager

Apple keeps its own register of what a company bought: Apple Business Manager (or Apple School Manager). Under Settings you connect it with the client id, the key id and the private key Apple issued — the key never leaves your browser: it signs one client assertion there (ES256, valid 180 days, Apple's maximum) and only that assertion reaches the app, which trades it for one-hour tokens and reads two lists every six hours — the organisation's devices and which device-management service each one is assigned to. Serials that exist in the register are linked and show an "Apple Business Manager" box on the device; the rest are the gap: devices the company owns but nobody has handed out through this register. The Apple page lists them, with a filter for those no device-management service holds at all. The filter Sold — release in ABM is the other direction: devices the register says are sold, scrapped or lost but Apple still lists — release them in Apple Business Manager once the invoice is paid, otherwise the buyer is forced into your device management at setup; after the next sync they disappear from the list. "Add" takes a device into the register as unknown — Apple, model, capacity, ordered when, from whom — until someone finds it and records the hand-over; as soon as an MDM sees it, the MDM sync links it by serial. Nothing is ever written to Apple. The API account's role must allow reading devices — Apple's Read Only answers 403 to every read (verified); use the smallest role that works for you. Before the 180 days end, drop the .pem again on Edit — the Settings card warns two weeks ahead.

Device trust

The trust app checks whether devices are in good shape and shows each person their own devices. To know whose device a serial is, it asks this register — once you allow it under Settings → Device trust (paste the id Trust shows). It receives serial and e-mail for assigned devices, nothing else, and only that one canister may ask.

Selling devices

Start a sale from a device, choose the buyer and agree the price. Colleagues see their offer under Offers & invoices and accept with their own Hub sign-in.

For an outside buyer, use External dealroom → Create private link, then copy and send that link. The buyer reviews the price and terms, completes their address and accepts without an account. Their invoice is generated and archived automatically. They download it and explicitly confirm receipt; you receive a Hub notification, with Slack delivery if configured. Opening a room or requesting a download is recorded separately from acceptance and receipt.

A dealroom link lasts 14 days. You can revoke it or create a replacement; the previous link stops working. Anyone holding the link can respond for this buyer, so keep it private. Changes to the offer or invoice settings need a new link. Issued PDFs stay unchanged.

For new dealroom sales, first confirm payment from your bank record, then save the wipe/MDM checks, release the device in ABM if necessary and record hand-over. Only that final step marks the device sold. An unaccepted offer can be declined in the room and is cancelled automatically. After invoicing, IT cancels with a credit note and arranges any refund. Older external invoices can also get a room for download and receipt confirmation.

Invoices and credit notes stay in the archive. Finance receives them through Sales → Export. Receipt confirmation is not payment confirmation. Swiss QR-bills use a normal CH/LI IBAN with SCOR; QR-IBAN/QRR is not supported. The pricing rule, VAT treatment and sale terms are configured by your organisation.

Not yet

Barcode/QR reading in the browser; approvals for hand-overs; per-person self-service returns; pushing the register's tag back into the MDM; sending invoices by mail from the app; QR-IBAN/QRR references; AppleCare coverage per device.