GuardCore · Security client portal
A security client portal your customer opens themselves
Who is on site, the patrols and tours, their incidents, their visitors — with what is yours withheld in the door’s own query rather than hidden in the page.
The problem this solves
The data a security customer wants to see sits in the same tables as your cost of delivery, your guards’ personal records and your commercial position. That is why "just give them a login" is harder than it sounds, and why most contractors send a PDF instead.
Hiding a column in the interface is not a control — anyone who opens the network tab has it. GuardCore’s portal resolves exactly one customer from the site selected, refuses outright when a contact is linked to no client rather than widening to the organisation, and enforces the service line at the door: a customer who buys cleaning only cannot reach a security screen by typing its address, because the check is in the handler and not in the menu.
What they get is the part that renews contracts. Who is on site right now. The patrols and tours, with the missed ones visible rather than quietly absent. Their incidents — filtered to the client-visible ones, with the narrative and the guard removed in the query. Their visitors, which they can pre-register themselves.
Reporting is built the same way round. Six datasets, each fixing its own field allowlist and its own client profile, so timesheets and licences are not client-readable at all and an incident dataset drops the narrative before it is rendered. And one limit worth naming: report acknowledgement is not built, so the portal does not pretend a read-only contact can sign one off.
Worked example
A client’s facilities manager signs in the morning after an overnight incident.
- 1
One customer is resolved, not inferred
From the site they selected, validated against their own rows. A site that is not theirs is not-found rather than forbidden.
- 2
They see who was on
Duty state derived from the roster, so the portal and the control room cannot disagree about who was there.
- 3
They open the incident
Their own view of it: the client-visible fields, with the guard and the narrative removed in the query that fetched it.
- 4
They pre-register tomorrow’s contractor
And the visit lands in the same register the gate works from, with an expected arrival on it.
The monthly meeting reviews something the customer has already seen, rather than presenting something they have not.
Capabilities
What security client portal gives you
All 4 of these are in the product today. Each one names what it is built on.
A portal the customer opens themselves
LiveWho is on site, the patrols and tours, their incidents, their visitors — and the service line is enforced at the door rather than in the menu, so a customer who buys only cleaning cannot reach a security screen by typing its address.
The customer books their own visitors
LiveA visitor pre-registered by the customer in their own portal lands in the same register the gate works from, so reception is not transcribing an email at eight in the morning.
Reports that know who is reading them
LiveSix datasets, each fixing its own field allowlist and its own client profile: incidents are filtered to the client-visible ones with the narrative and the guard removed, and timesheets and licences are not client-readable at all.
Reports that arrive without being asked for
LiveDaily, weekly, fortnightly, monthly or quarterly, at a time you set, rendered by the background worker — and the run row survives the retention window even after its output is deleted, so the history of what was sent stays.
What backs these claims
Each capability names the decision record, module, route or table it is built on. Ask us for any of them in an evaluation and we will walk you through the code.
- A portal the customer opens themselves
- ADR 0064 · src/server/imss-client-portal.ts requireServiceLine · client-portal/on-site · client-portal/patrols · client-portal/incident
- The customer books their own visitors
- client-portal/visitors · src/pages/imss/client/guardcore/ClientVisitors.tsx · src/server/api/imss/client-portal/POST.ts
- Reports that know who is reading them
- src/server/imss-report-executor.ts · GET /api/imss/reports · /imss/reports
- Reports that arrive without being asked for
- src/server/imss-report-schedule.ts nextRunAt · src/server/imss-jobs/report-schedules.ts
Where this sits
Back to
GuardCore — every capability in one place
The whole module: what is live, and what is only on the roadmap.
Read next
Incidents with a clock that escalates without being asked
An acknowledgement clock and a response clock, each scaled by severity and measured against the site’s own minutes — swept in the background, escalated once per level.
Twenty minutes on a real contract.
Real data, four logins, nothing typed on the day — including the parts we have not built, which we will point out ourselves.