Alerts & Bulletins

Alerts and bulletins are safety notices surfaced to field users — typically on the prestart they complete at the start of a shift. An admin raises an alert (or a non-mandatory bulletin) against a project; field users see it, acknowledge mandatory ones, and can open its attachments.

Alert types

Two settings decide how an alert behaves: Mandatory, and an optional Alert Date. There are three combinations.

Setting a date makes an alert mandatory. The Mandatory switch ticks itself and locks while a date is set — an alert nominated for a specific day is always one the crew has to answer. Clear the date to make the alert optional again.

The same three cases are behind the ? next to the Mandatory switch, on web and in the mobile app.

On the prestart

An alert with a date appears automatically on prestarts for that date. Every other alert — mandatory or not — appears once a supervisor acknowledges it in Manage Alerts, the same as in Lacroo Core. Until then it waits there, and the Manage Alerts button carries the number waiting, e.g. Manage Alerts (3). A mandatory alert still has to be acknowledged on every prestart: a prestart published without it counts as awaiting acknowledgement (see below).

Marking an optional alert N/A takes it off the prestart. Nothing is lost: it keeps its row in Manage Alerts, the answer is recorded in the alert’s audit log, and Clear brings it back.

Alerts on the prestart are grouped Mandatory first, then Optional, and each shows where it stands:

• Acknowledged — a supervisor confirmed it.
• Pending — an alert with a date, still unanswered.
• Not applicable — an alert with a date that was waived while it was optional.

The printed prestart shows the same alerts, in the same order, with the same status. Alerts are a prestart record; they do not appear on the diary or its print.

Manage Alerts

Manage Alerts on a draft prestart is where the answers are given. It lists every alert available to that prestart — what it is, who issued it, when, and where it stands.

• Acknowledge confirms the alert.
• N/A waives it. Offered only on alerts that can be waived, so a mandatory alert has no N/A button.
• Clear takes an answer back and returns the alert to unanswered. Use it when the wrong row was answered.

Tick several alerts to answer them together. Not applicable on a mixed selection says how many of the selected alerts it applies to, and answers only those.

The list is ordered mandatory first, then oldest first, and answering an alert never moves it — the row stays put, so the next one is where you expect it.

Every answer is recorded, including a change of mind and a cleared response. The alert’s audit log shows what was recorded and what it replaced.

The same actions are in the mobile app, on the prestart’s Manage Alerts sheet.

Alert lists

There are two lists: Project Alerts under Health & Safety in a project, and Alerts in the organisation console.

Project Alerts also shows the organisation alerts sent to this project. They carry an Organisation badge and are read-only there: they can’t be ticked, edited, duplicated or archived, and their photos and files can’t be added or removed. Change them on the organisation’s Alerts page.

On either list, tick alerts to change Mandatory, the date or the type together, or to export only those — see Bulk Edit & Undo. On Project Alerts, bulk actions, including selecting every match, apply to the project’s own alerts only.

A date filter on Project Alerts covers whole days in the project’s time zone, both included. Selecting every match uses the same days.

Pasting from Word or Excel

Text pasted from Office keeps its formatting, and the hidden styling Office puts on the clipboard is discarded rather than stored as part of the alert.

Dashboard metrics

Four tiles sit above the alerts list, each reflecting the time range picked beside them.

• Active Alerts — alerts and bulletins that have not been archived, including organisation alerts sent to this project.
• Response Rate — the share of active alerts (bulletins excluded) that at least one person has answered.
• Awaiting acknowledgement — alerts that a published prestart went out without anyone acknowledging.
• By Type — the active count split into alerts and bulletins.

What this tile counts

Only a mandatory alert with no date can be awaiting acknowledgement. Each published prestart that went out without it is one thing outstanding, as long as the prestart:

• was made in Lacroo Pro. Prestarts brought across from Lacroo Core are never counted, because Core never tracked this;
• is dated on or after the day the alert was issued, in the project’s time zone.

The tile shows how many alerts those add up to.

An alert with a date never counts here: it is added to the prestart on its date automatically, so it was put in front of the supervisor and nothing was missed. A bulletin and a non-mandatory alert never count either — neither is something anyone is obliged to answer.

The deadline is the moment a prestart is published, not the day it was scheduled for. A prestart left in draft was never put in front of anyone, so it never counts against you.

A tile reading 0 means nothing is outstanding. Most projects will read 0 until someone raises a mandatory alert with no date.

Attachments

An alert can carry photos and file attachments. Files are stored in object storage and listed on the alert; non-media files render as a download chip.

Upload progress

Every file you attach gets its own row on the alert’s Media & Files tab, from the moment you pick it until the server has it: the file’s name, a progress bar, and the bytes sent so far — “12.4 MB of 93.8 MB”. Attachments here routinely run to tens of megabytes, which on a site connection is minutes of transfer, so the progress is per file rather than one label for the whole selection.

• One file failing does not sink the batch. The failed row says why in a line — “Connection lost.”, “File is too large.” — and offers Retry, which re-sends that file only. Every other file carries on.
• Cancel stops a single upload and drops its row.
• Uploads survive moving around the modal. Switching to Alert Detail or Audit Log while files are going up does not interrupt them; the rail entry keeps counting what is still on the wire, and turns red if something fails while you are looking elsewhere.
• On mobile, the same rows appear under the alert’s Files section with a progress bar each, and a large video keeps uploading while the phone is locked.
• Over-size files are refused before any bytes move: 20 MB per photo, 500 MB per file.

Video (MP4)

Alerts and bulletins accept MP4 video attachments so a safety team can embed a short hazard walkthrough directly in the notice. Video plays inline — field users tap play without leaving the alert — on both web and the mobile app.

• Format: video/mp4 only. Other video containers (WebM, QuickTime/MOV) are rejected with a clear message; pick or export an MP4.
• Size: up to 500 MB per video. Larger files are blocked client-side before the upload starts.
• Playback: the stored MP4 is played natively (HTML <video> on web, the native video view on mobile). There is no transcoding — if a file uses an unusual codec inside the .mp4 container that a device can’t decode, it falls back to a download link. Standard H.264 MP4 (what phones and most editors export) plays everywhere.
• Where it shows: the field-user prestart view, the admin create/edit alert dialog, and the mobile alert detail screen.

How the upload works

A 500 MB file is too large for the normal app→server path (the web Server Action and the mobile API proxy both cap request bodies well below that). So the app requests a short-lived upload token from the BFF, then uploads the file straight to the Go API, which validates it (MP4, ≤500 MB) and stores it alongside the alert’s other attachments.

On the web this is now the route for every attachment, not only video: the Server Action body cap is 10 MB — below the size of a typical alert attachment — and it cannot report upload progress, so photos and documents from the Media & Files tab take the same direct route. The BFF still does the authorising; it mints the token off the signed-in session.

On mobile the routing is unchanged: MP4 goes direct to the API, everything else proxies. Both now report bytes as they leave.

Notes & limits

• Video attachment URLs are public by URL, the same model as alert photos and other file attachments — treat a safety video as shareable-by-link.
• No poster/thumbnail, duration probe, or caption track is generated in this version (a future processing pass can add these). Captions are not yet supported, so avoid relying on audio-only narration for accessibility-critical content.
• Deleting a video attachment removes the underlying stored object (best-effort cleanup).