Report Templates - Conditional Fields
Overview
Report Templates now make it easier to ask guards the right question at the right time. Condition Fields let a field's answer show or hide other fields, so guards only see follow-up questions when they're relevant instead of scrolling past fields that don't apply. This release also includes a redesigned Field Setup builder for creating and managing these rules.
Alongside this, Groups and Libraries make conditions easier to manage at scale: a Group bundles several fields together so one rule can show or hide all of them at once, and a Library is a reusable set of fields that can be shared across multiple report templates.
What it does
A field's answer can now trigger a rule that shows or hides other fields on the same report template. For example, a "Have you called the police?" field can reveal a "Did the police arrive?" field only when the guard answers Yes.
Why it matters
Instead of showing every field to every guard, the template only surfaces the questions that apply to their situation. This cuts down on noise and confusion in longer report templates and keeps guards focused on the right questions at the right time.
How to configure it (Help Desk)
UI Changes
Conditional Fields Notifications
Overview
Report notification rules could already be filtered by report template, incident severity, incident flag and incident flag type. They could not be filtered by how a specific question inside a report was answered, which meant that any rule matching the template fired on every submission of that template, regardless of what the person on site actually reported.
This release adds a Conditional Fields filter to report notification rules. Where a report template has conditional field rules configured, those rules now appear inside the notification rule as individually selectable items. Selecting one means the notification is sent only when that specific conditional rule is satisfied by the submitted report.
The practical effect is that one report template can drive several different notification paths. A submission answering a question one way reaches one distribution list; a submission answering it another way reaches a different one, or nobody at all. This closes a long-standing gap for customers migrating from legacy platforms that supported answer-based notification routing.
Conditional Fields filter on report notification rules
What it does
When you edit a report notification rule and open Filters and recipients, the Report Send via Email/SMS panel now contains a Conditional Fields folder alongside the existing Form Templates, Incident Severity, Incident Flag Type and Incident Flag folders.
The Conditional Fields folder lists every report template available to that site or zone that has conditional field rules configured against it. Expanding a template exposes its individual rules as selectable items. Select one or more, and the notification is sent only when a submitted report satisfies a selected rule.
Why it matters
Customers can route a single report template to different recipients based on the answers inside it. A severity question, an escalation question, or a "who did you call" question can each drive its own notification and its own distribution list, without duplicating the report template or building separate templates per outcome. It also removes the noise problem of every recipient on a template-level rule receiving every submission.
How to configure it
TT-Shift - LoneWorker
Safety - LoneWorker Check-In's on TT-SHIFT App
Overview
Guards can now signal their presence for scheduled Lone Worker check-ins directly from the Shift app. Previously, signalling presence required either the guard tour app or a call-in from an authorized phone number, which left shift-only staff without a way to confirm they were safe. Guards using the Shift app can now confirm presence in two places: the clock-in screen and a dedicated Lone Worker screen that shows the full day’s check-in schedule.
This matters most to security operations teams who staff lone-worker posts with employees who do not carry a guard tour licence. It extends check-in coverage across the whole roster without changing how supervisors configure or monitor Lone Worker schedules.
Signal Presence from the clock-in screen
What it does
Once a guard has clocked in to a scheduled shift, a Signal Presence action appears on the clock-in screen alongside Clock Out and Take Break. Tapping it records the check-in against the scheduled time.
Why it matters
The check-in sits on the screen guards already have open during a shift, so confirming presence takes one tap and does not require finding a separate screen or a landline.
How to access it
Lone Worker screen — the full day’s schedule
A dedicated Lone Worker screen lists every scheduled check-in for the day with its status: completed, upcoming, or missed. Guards can also signal presence directly from this screen. It gives the guard a running view of what has been confirmed and what is still due, rather than a single prompt at the moment of the check-in.
Check-in reminders — in-app alert and push notification
What it does
The Shift app now prompts guards when a check-in is due. If the app is open, an audible alert sounds at the scheduled check-in time and again one minute before the grace period ends. If the app is in the background, the guard receives a push notification asking them to signal their presence for that check-in time.
Why it matters
Missed check-ins raise exceptions that supervisors then have to resolve. Prompting the guard on the device twice — once at the scheduled time and once before the window closes — reduces the number of check-ins that lapse simply because the guard was occupied.
Prerequisites
What has to be true before a guard can check in.
Region Search Filter
Overview
The Regions panel now includes a search field. Type any part of a region name and the region tree narrows to the regions that match, so reaching a specific region no longer means scrolling the full list or using your browser’s find function.
This change was requested by customers running large region hierarchies — portals with several hundred regions across multiple levels — where locating a single region was consistently slow. Search results respect existing region permissions: users see only the regions they already have access to.
What it does
A Search regions field sits at the top of the Regions panel, directly beneath the panel header. As you type, the region tree filters down to regions whose names contain what you entered. Clearing the field restores the full tree.
Why it matters
On portals with large region hierarchies, finding a region previously meant scrolling the entire tree or using browser find. Search reduces that to a few keystrokes, and because parent regions stay visible in the results, similarly named regions in different branches remain easy to tell apart.
How to access it
Open the Regions panel on the left side of the portal. The Search regions field appears directly below the Regions header, above the region tree. No setup or permission change is required.
How the search behaves
Post Orders
Post Order Versioning
Overview
Post Orders now keep a full version history. Every time a post order is saved, the platform stores a snapshot of that revision — its content, its attachment, and who had read it at that point in time. Administrators can open any past version and see exactly what guards were shown and when they acknowledged it.
The driver is audit and legal defensibility. Customers operating under contractual or regulatory scrutiny need to prove which instructions were in force on a given date and which staff had acknowledged them. A post order stored as a plain document cannot carry that proof; a versioned record with acknowledgement timestamps can.
The same release introduces archiving for post orders. An archived post order is withdrawn from active use without being removed from the platform: it keeps its version history and its read rate, and it can be restored at any time. Administrators who would rather nothing was ever deleted outright now have a reversible alternative.
What it does
Every save of a post order creates a version snapshot. A new Version History tab appears beside the existing Read tab on the post order detail panel, listing each version with its number, the date and time it was saved, and who saved it. Selecting View on any row opens that version in full.
Why it matters
Administrators can produce a defensible record of which instructions were published, when they changed, and which staff acknowledged each revision — without maintaining a parallel set of documents outside the platform.
How to access it
Open a site, go to Operation Reports › Post Orders, select View on a post order, then open the Version History tab in the right-hand panel.
Reset Acknowledgements and Notify Users
What it does
When editing a post order, a Reset Acknowledgements and Notify Users checkbox controls whether the existing read rate carries forward. Leave it selected and the read count clears, staff are asked to acknowledge again, and users on the mobile app are notified of the new version. Clear it and the existing read rate is preserved.
Why it matters
It separates a substantive change from a correction. Fixing a typo no longer forces an entire site to re-acknowledge an instruction they have already read, while a material revision can still be pushed out for fresh acknowledgement. Either way the choice is recorded against the version.
How to configure it
Open a post order, select Edit, make the change, then set the checkbox before saving. The resulting version records the outcome as Acknowledgements Reset: Yes, or No
Archive and Unarchive Post Orders
What it does
A post order can now be archived instead of deleted. Archiving withdraws it from active use while leaving the record itself intact, and an archived post order can be restored at any time with Unarchive. Neither action affects the version history or the read rate — both carry through unchanged in either direction.
What changes on the Post Orders list
Why it matters
Post orders carry contractual and legal weight, so permanently removing one is rarely the right outcome. Archiving lets an administrator retire an instruction that no longer applies while preserving the record of what was published and who acknowledged it — and reverse that decision if it turns out to have been made in error.
How to access it
Open a site, go to Operation Reports › Post Orders, then select Archive on the post order’s row and confirm. To bring it back, select Unarchive on the same row and confirm.
Post order archive permissions
What it does
Two permissions have been added to the permission tree under Patrol › Post Orders: Archive and Unarchive. They are granted independently of each other and of Delete, so a role can be allowed to archive a post order without being allowed to restore it, or allowed to do both without being allowed to remove anything permanently.
Why it matters
An administrator who does not want post orders leaving the system at all can now withhold Delete and grant Archive and Unarchive in its place. Nothing is then removed from the platform, and the version history behind every post order stays complete — which is the point of versioning in the first place. How the two permissions are combined is left to each customer’s own policy.
How to access it
Go to Settings › Roles & Security › Roles/Permissions > (Admin or Staff Role) Customer > Post Orders > Archive and/or Unarchive
Post Order Push Down
Overview
Post orders can now be published from a zone or a multi-site down to the sites beneath it — either to every site at once or to a specific selection. A post order that has been pushed down is read-only at the receiving sites: site-level users can open and acknowledge it, but they cannot edit or delete it. Control stays with whoever manages the parent record.
Acknowledgements follow the reader rather than the location. When a guard acknowledges a pushed-down post order, that acknowledgement is reflected everywhere the post order appears — at the parent zone or multi-site and at every site it reached — so managers see one accurate read count instead of reconciling several.
This is aimed at operations teams who maintain the same standing instruction across many sites: a fire safety plan, a chemical spill procedure, a harassment policy. Previously that meant creating and maintaining the same document site by site, with no single place to confirm who had actually read it.
Post order propagate to specific sites
What it does
Adds a new permission, Propagate to specific sites, that controls whether a user can push a post order down from a parent record to the sites beneath it. The permission sits alongside the existing Post Orders permissions — View, Create, Edit, Delete, Acknowledge, and Unacknowledge.
Why it matters
Pushing a post order down writes a read-only record into every site it reaches, and those sites cannot remove it themselves. Gating that behind its own permission means the ability to publish across a portfolio can be granted to the handful of people who should hold it, without also granting it to everyone who can create a post order at a single site.
Who it applies to
The permission is available on administrator roles and on staff portal roles.
How to access it
Push post orders down from a Zone
What it does
When creating or editing a post order at zone level, two new options appear in the post order dialog:
If the specific-sites option is selected and no sites are picked, the dialog blocks the save and shows: "No sites selected. Please select at least one site to propagate the post order."
Why it matters
A standing instruction that applies to part of a zone no longer has to be created site by site, and no longer has to go to every site in the zone just because it originated there. Portfolios where sites differ — a zone covering both staffed buildings and unstaffed lots, for example — can target the sites the instruction actually applies to.
What the receiving sites see
At each site that receives the post order, the Post Orders list shows the parent zone in the Propagated From column, and the row offers a View action only. Edit and Delete are not available. Site-created post orders in the same list continue to show N/A in Propagated From and keep their full View, Edit, and Delete actions.
How to access it
Push post orders down from a Multi-Site
What it does
The same capability is available from a multi-site. The two options in the post order dialog are labelled for the multi-site context:
Behaviour is otherwise identical to zone push-down: the same site picker, the same validation when no sites are selected, the same read-only result at the receiving sites, and the same acknowledgement handling described below.
Why it matters
Zones and multi-sites group sites for different operational reasons. Supporting both as a publishing source means teams can push a standing instruction from whichever structure reflects how they actually manage the portfolio, rather than rebuilding their hierarchy to suit the tool.
How to access it
Acknowledgements reflect across every level
What changed
An acknowledgement is recorded against the reader and the post order, not against the place the reader happened to open it. Once a guard acknowledges a pushed-down post order, that acknowledgement appears everywhere the post order exists — at the parent zone or multi-site and at every site it was pushed to. The direction does not matter: acknowledging at the parent updates the sites, and acknowledging at a site updates the parent.
How the two columns differ
The Post Orders list separates read counts into two columns, and which one a reader lands in depends on whether they are assigned to the record being viewed.
| Column | What it counts | Reads as |
|---|---|---|
| Read (Assigned) | Users assigned to this zone, multi-site, or site who have acknowledged the post order. | A ratio — acknowledged over total assigned (for example, 1/12). |
| Read (not Assigned) | Users who acknowledged the post order but are not assigned to the record being viewed. Typically a guard who read it at a site and is not assigned to the parent zone. | A single count. |
What this looks like in practice
Selecting a read count opens a panel listing the individual users and the date and time of each acknowledgement.
Why it matters
A post order that spans a zone and twelve sites previously produced separate, partial read records. One reader who acknowledged once could look unread from another level, and confirming who had actually seen a mandatory instruction meant checking each site in turn. A single acknowledgement now settles the question everywhere, which is what makes the read count usable as a compliance record.
Back Office
Future Termination Date Management
Overview
A future termination date set on an employee is now enforced across scheduling. Previously a last day of work could be recorded, but the platform did not consistently prevent that employee from being scheduled beyond it, so upcoming shifts had to be found and cleared by hand.
The employee’s last day of work is now a hard boundary. The employee cannot be assigned to a shift that starts after that date, and no role can override the block. Shifts already assigned beyond the date are released automatically when the termination is recorded, rather than waiting for the date to arrive.
What’s new
Notes and limitations
How to access it
Open an employee, select Terminate, and set the Last Day of Work with a termination reason. The profile header and the employee’s History tab reflect the change.
Break Penalty Approval — Paycode Visibility & Export
Overview
The Break Penalty Approval page now shows the penalty paycode that will be applied to each missed break, and the list can be filtered by it and exported.
Break rules tie each required break to a penalty paycode, and that paycode determines the payroll outcome. Until now it was not visible on the approval page, so a reviewer had to look it up elsewhere to confirm the right code was attached — or discover the problem after payroll had run.
What’s new
Why it matters
Reviewers can confirm the correct paycode before approving a penalty, which catches misconfiguration before payroll processes it rather than after. Payroll and compliance teams can take an offline record of the list for reconciliation and audit trails without re-keying it.
How to access it
Open the Break Penalty Approval page. The new column appears in the table, and the filter and Export controls sit with the existing list controls.
New Payment Term — Net 28
Overview
Net 28 is now available as a payment term. A payment term is the rule attached to a contract that tells the billing engine when an invoice falls due relative to its issue date — Net 28 means the full amount is due 28 days after the invoice date.
Net 28 was not previously in the list, so customers billing on a 28-day cycle had to approximate with the nearest available term. It now sits alongside the existing options.
What’s new
How to access it
Open a site contract and choose Net 28 from the Payment Terms list, or set it as the client default under Billing Settings & Preferences.
