Move an event to another site, and the “Awaiting classification” report

An event always belongs to one site (and often to a plant). Two situations call for changing that: the event was recorded in the wrong place, or it came in through the company-level reporting channel and has no site yet — such an event is “Awaiting classification”. Both work the same way: you reassign it in the side panel, with a mandatory reason, and the event gets a new identifier from the target site’s number series.

Before you start

• Permission: reassigning events — event:reassign (“Reassign events” in the permission matrix). By default it belongs to the site manager, the production manager and the administrator; the admin can delegate it on the Permissions page, but only a right they can exercise themselves.
• Access: you need access to both the source and the target site. A target site you cannot reach is not offered in the picker.
• Who sees an “Awaiting classification” event? Only people with company-wide scope (they see every site of the organisation) and people who hold the reassign permission. Everyone else — in the shift log, the shift PDF and the reports — does not see it: an event without a site belongs to no site’s list until it is classified.

The “Awaiting classification” event

An event with no site reaches the Reports → Events table in two ways:

• as a report through the company-level channel — one QR code or link for the whole organisation (you create the channel under Master data → Field reports, with company-wide scope; see Field reports by QR);

• recorded by a signed-in user with the Record company-level event button — in the Shift diary’s Events element, or above the table —, when you don’t know which site the event belongs to (see below).

• The row carries the Awaiting classification badge, and a Company-level report chip among the Filters isolates them — both are shown only to people who can see these events.

• Its identifier is not site-based yet: E-<YEAR>-CEG-<number> (for example E-2026-CEG-3).

• It has no plant, shift log, permit or technical location — those only make sense on a site, after classification.

Record a company-level event as a signed-in user

If you notice something and don’t know which site it belongs to — for example on the road between two sites —, record it with the Record company-level event button. You find it in two places, with the same form:

• in the Shift diary, at the header of the Events element — for people who hold the event-recording permission (event:create; by default the shift leader);
• on the Reports → Events page, above the table — if you can also open the Events tab (report:events).

1. Press Record company-level event.
2. Enter the Title and the Type (the Subcategory if the type has one; for an HSE type the severity is required). Description, Location (free text), Started / Ended and the Caused downtime / Caused production loss ticks are optional.
3. Press Record.

• The event becomes “Awaiting classification”, with an E-<YEAR>-CEG-<number> identifier and your name as the reporter. Its source is shown as Recorded outside the shift log (not a field report) — even when you recorded it from the shift log: a company-level event does not go into the log or the shift PDF.
• You can’t attach a photo here, nor link a plant, shift log or technical location: the photo and these links belong to a site, and a company-level event has no site until it is classified.
• If you have neither company-wide scope nor the reassign permission, you won’t see the event after recording it, nor get its identifier — the app says so (“Recorded and handed over for classification”). After classification it appears under its target site; you see it there if you have access to that site. Recording does not give you read access to other “Awaiting classification” events.

Steps

1. In Reports → Events, click the event. In the side panel press Assign to a site… (for an unclassified event) or Move to another site / plant….
2. Choose the Target site and, if needed, the Target plant (optional). Without a plant the event becomes a site-level event outside any shift log.
3. Enter the Reason — required (up to 2000 characters). Exception: classifying an event “Awaiting classification”: there the reason is optional (the field says “Reason (optional)”) — the classification is the reason, and the fact, its time and who classified it are recorded even without one.
4. Press Assign to … — with a new ID (or Move to … — with a new ID).

What happens when you move it

• It gets a new identifier from the target site’s number series (the year stays the event’s original year). The old identifier is kept as “Previous ID”: it shows in the panel header, in the table and in the export, and you can search for it — so the old reference still finds the event.
• The timeline shows a Reassigned entry with the reason, and the old and new place by name (site, plant). The event’s original “Recorded” entry shows the source the event had when it was recorded.
• Its status is kept — moving never opens or closes an event. Comments, edit history, supplements and the event’s photos move with it.
• If the event was bound to a shift log, it leaves the log when moved (see below).

When the event is bound to a shift log

The event’s log	What happens	What you need
No log (off-diary, site-level)	You can move it at any time.	event:reassign
Open log	The event leaves the log — free editing, there is no official record yet.	event:reassign
Closed log	The move is a correction: a reason is mandatory, the timeline marks it as a correction, and the log’s PDF gets a new version (the old one is superseded but kept).	event:reassign and shift_log:correct

The panel tells you in advance which case applies, and the button label says so too (… — new PDF version). Correcting a closed log in detail: Handle events from the table.

When moving is blocked

If the event has a linked item — a work order, a work permit or a task — it cannot be moved: those belong to the source site and must not move silently. The button is disabled and the panel names what to settle first (the linked work order, permit or task). Once the link is gone — for example an archived work order no longer counts as linked — the move is available.

If you did it right

The panel says “Moved. New ID: …”; the event is in the new site’s list, shown in the table with its new identifier — and the old one under Previous ID. The “Awaiting classification” badge is gone.

Common problems

What you see	Why	What to do
No “Move” button	You do not hold the reassign permission.	Ask your admin. You can still comment or change status if you have those rights.
Disabled button: “Cannot be moved because it has a linked item: …”	A work order, permit or task is linked to the event.	Settle the link first, then move it.
“The log is closed: moving the event also needs the log-correction permission, which you do not have.”	The event is bound to a closed log and you cannot correct logs.	Ask a colleague with log-correction rights to move it.
“A reason is required to move the event.”	The reason field is empty (moving an already classified event, or a correction).	Enter a reason.
“The target site is not available.” / “There is no site you have access to …”	You have no access to the target.	Ask for site access, or ask a colleague who has it.
“The event is already at this site / plant.”	The target equals the current place.	Choose a different site or plant.
I cannot see “Awaiting classification” events	You have neither company-wide scope nor the reassign permission.	That is by design — nobody else sees them. Ask the admin if you are meant to classify.

Good to know

• No way back: a site event never becomes “Awaiting classification” again — it can only be moved to another site.
• One path. Fixing a wrongly placed event and classifying an “Awaiting classification” one are the same move — there is no separate procedure.
• The trail stays. The move (who, when, from where to where, why) is kept on the event’s timeline and in the system audit log, and cannot be deleted.
• No photo on a company-level event today: neither the company-level channel nor signed-in recording can attach a picture to an “Awaiting classification” event.
• The company-level channel is internal (a QR label or link for staff, contractors and visitors); the public (resident) page works per site and does not create “Awaiting classification” events — see Public (resident) reporting page.

Related

Handle events from the tableStatus, comments, editing and correcting a closed log.

Field reports by QRChannels at plant, site and company level, and their fields.