Reporting Problems
A fault reported in prose — "the unit in the back room is making a noise" — costs someone a round trip to work out which unit. A fault reported from the machine's own page arrives already attached to it.
The Form on the Record Page
Any location or asset can carry a Report a problem form on its own page. It takes a short subject and optional details, and files a ticket already linked to that record.
The person filling it in does not need to find the tickets screen, know your ticket categories, or describe which machine they mean. They are already looking at it.
The form appears to:
- Signed-in staff and clients viewing the record in the portal
- Anyone you sent a share link to, on the public view of that record
Turning It On
The form is off on every record until you switch it on. Upgrading does not open a reporting channel on equipment you already have on the system.
Two switches have to agree:
- Site-wide. Asset tickets or location tickets must be enabled under Settings → Core Features. Until they are, the per-record option does not appear at all.
- Per record. Open the record, go to Edit → Settings, and switch on Show the support form on this asset (or …on this location). Save.
Switch it on for the equipment that generates call-outs. Leave it off for the rest — a record with no form is simply a record, and nothing about it changes.
Who Can File, and as Whom
The form works out who someone is from whatever they already hold, rather than asking again:
| Who is looking | What they do | Ticket is filed as |
|---|---|---|
| Signed in to the portal | Fills in the form directly | Themselves |
| On a PIN-gated share link | Nothing extra — already identified at the gate | The PIN's owner |
| On an ordinary share link | Enters their access PIN in the form | The PIN's owner |
| Not identifiable at all | Cannot file | — |
That third row is the reason the second exists. If a share link already required a PIN to open, asking for the same PIN again to report a fault on the page in front of them would be pure ceremony. They are recognised from the gate.
Every ticket carries a real author. Nothing arrives from "nobody".
Reporting from a QR Scan
The scan page described in Field Access & PINs carries the same report form, below the record's details.
This is the flow the whole feature is built around: someone finds a fault, scans the sticker on the equipment, enters their PIN, checks the title matches what they are standing in front of, describes the problem, and walks away. No login, no app, no phone call, and no ambiguity about which unit they meant.
A Form on Your Own Website
The same form can be embedded on a site you do not control — your own marketing site, or a customer's intranet.
Set it up at Tickets → Embed form:
- Allow the site. One origin per line, for example
https://acme.com. Until you add a site here, the form cannot be embedded anywhere. That is the safe default, and deliberately not "allow everyone" — it is what stops someone standing up a convincing copy of your support page to collect PINs. - Paste the snippet into their site. A single script tag.
- Optionally tie it to one asset or location. Search for the record and copy the bound snippet instead. Requests from that form arrive already attached to that piece of equipment, and the form tells the visitor which one it is filing against.
The form is served from your portal inside a frame rather than built into the host page, so nothing else running on that site — their analytics, their plugins, anything injected — can read what someone types into it.
Where the Ticket Lands
A report becomes an ordinary ticket. It appears in Tickets, it can be replied to, assigned, and closed like any other, and it triggers the same notifications and automations.
Two details are decided for you:
- It is linked to the record. An asset report sets the ticket's asset; a location report sets its location. The link is what makes "show me everything that has gone wrong with this unit" answerable later.
- It belongs to the record's client — not to whoever noticed the problem. A fault on a client's equipment is that client's ticket whether it was reported by their office manager, your technician, or a contractor. This is also what lets your own staff use the form: they belong to no client, but the machine does.
If a record has no client and the person filing has none either, the form declines rather than filing an orphan ticket.
New reports open with status Open and medium priority.
What Nobody Can Do
Worth stating plainly, because the form is reachable from outside the portal:
- File anonymously. Someone the portal cannot identify — no login, no share session, no PIN — cannot open a ticket.
- Report against equipment they cannot see. The record has to be one their account already permits. A different ID in the URL does not help.
- Reach anything else. A session opened to report on one asset covers that asset. It is not a portal login and does not become one.
- Guess a PIN at leisure. Five attempts per fifteen minutes.
Choosing Where to Put a Form
| Situation | Where the form goes |
|---|---|
| Equipment that generates call-outs | On the record, plus a QR sticker |
| A client who reports by email and you would rather they did not | On the record, shared by PIN-gated link |
| A customer with their own website and their own staff | Embedded on their site, tied to the record |
| Equipment nobody else should be reporting on | Nowhere — leave the form off |
Start with one or two records rather than switching it on everywhere. The form changes who can put work into your queue, and it is easier to widen that than to narrow it once people are used to it.