Event Lifecycle Operations

Splitting an event#

Splitting turns one event into two at a chosen moment — the standard correction when operators want one downtime attributed to two causes.

What actually happens: the original period is superseded and two new periods are created (Infohub keeps versions — the original is retained as non-preferred, which is why audits can still see it). The side-effects:

• Time slices are rebuilt for the affected range, and on some versions the rebuilt slices did not regenerate until a backfill — if a form cell refuses entry right after a split ("no time slice"), backfill the measure across the split and it clears.
• Manually entered values sliced by the event are at risk. Manual data attached to slices of the original event does not automatically re-attach to the new pair; there are field reports of manual data loss following splits. Before splitting a range that carries manual data, export or note the values — they are the one thing that cannot be regenerated.
• Duration-derived attributes recalculate for both halves; counts change (one event became two), so Pareto and MTBF figures move.

Editing boundaries and inserting time#

Editing an event's start/end, or inserting a missing event into a gap, is done on the event form — with two rules learned from tickets:

• Do not close a gap by stretching a neighbour. Editing the previous event's end to meet the next event's start (instead of inserting an event into the gap) has left schemes stuck — attributes stop processing on the stretched event. Insert into the gap; don't stretch across it.
• Categorising an event before it has ended can stick it open on affected versions — the user's attribute write creates a preferred version whose end is NULL, and the trigger's later end never lands. The fixed behaviour ships in the 7.2.0 era (retired periods always close); on older sites, the operating rule is: complete the attributes after the event closes, and if one sticks, repair the NULL-end version.

Skipping forward past a data gap#

An event scheme processes its triggers in order and never moves past a period it cannot resolve. When the trigger's source stopped delivering data for a long stretch — a historian outage, a tag renamed and only later repaired — the scheme stays parked at the start of the gap, no new events are created, and every event-sliced measure above it goes stale. Before 7.2.0 the remedy was a support call.

Skip To on the Event Scheme form moves the processing position forward past the gap. The form shows the scheme's current position and enables the Skip To date and the Skip button once an active scheme's processing position is more than 21 days behind now; on a healthy scheme the controls stay disabled. Pick the date to resume from and press Skip:

• The date must be after the current processing position and cannot be in the future.
• The Data Engine applies the skip on its next pass: any event still open is closed at the current processing position, no events are created for the skipped range, and processing resumes at the date you chose. Until then the form reports the skip as pending.
• Skip To is offered on model event schemes only. A template has no processing position.

The same command is available from the Config CLI as --gap-skip-to with --gap-skip-to-date, which applies the same two checks before writing anything — see Complete CLI Option Reference.

Related, in the same release: the window an event trigger queries for new values on the Ignition, InfluxDB, OPC HDA, OPC UA and both AVEVA (Wonderware) historian data sources grew from 7 to 21 days, so a short outage no longer parks a scheme at all.

Permissions: who may do what#

The recurring requirement: operators may split and categorise but not add, delete, or move boundaries. The permission model is coarser than that wish — event editing rights on forms largely travel together, and granting attribute editing has historically meant granting boundary editing. Notes for configuring it honestly:

• The AllowAttributeEdit permission for event-based forms (added in the 7.2.0 era, ported from #2601) is the mechanism that separates "may fill in attributes" from "may edit the event" — with a companion fix stopping free-entry cells editing despite read-only.
• Anything finer (split-only rights) is not expressible today; enforce it procedurally, and log the requirement — it is a real, repeated ask.

See Users, Groups, and Access for the group model these rights hang off.

Very long events#

Multi-day events (a 16-day shutdown) are legitimate and historically fragile: schemes have struggled once a single event spans many periods — slicing effort grows, attribute reads span enormous segments, and sites have resorted to splitting long events into arbitrary 3–4-day chunks, which corrupts counts and MTBF.

The honest guidance until the underlying handling improves: model planned long outages as their own scheme (a Shutdown scheme) rather than as an ordinary stoppage, so the operational scheme's assumptions (events measured in minutes-to-hours) stay true, and the shutdown's duration lives where nothing derives cycle metrics from it.

Copying event data between schemes#

Wanting this usually follows a re-templating: a new scheme replaces an old one and history should carry over. There is no in-product copy; the realistic options:

1. Keep the old scheme undeployed-but-present for history, and start the new one clean — reports span both by union. Cheapest and safest.
2. Support-assisted migration at the database level — event periods and attribute values are relational and can be mapped, but identity, versions, slices, and template links make this a scripted, reviewed exercise, not an afternoon.

Budget accordingly, and challenge the requirement: history usually only needs to be readable, not re-homed.

Renaming event instances in bulk#

Instance names come from the template's instantiated-name pattern; adding a site prefix across ~1,500 instances is a pattern change plus update, with the caveats in Template Troubleshooting — a rename mismatch produces adds-plus-orphans, not renames. Test on one instance, verify the update matched rather than duplicated, then roll out.

Deleted events#

Deletion is versioned like everything else — deleted periods are superseded rather than physically erased (until archive/purge removes them), which is why an audit can reconstruct them but the UI does not surface them. The operational answer: recover-by-support is possible while purge retention lasts; treat purge age as the real deletion date. See the retention rules in The Maintenance Window.

Before any bulk event surgery#

1. Export the scheme (model export) and back up the database — versions make many mistakes recoverable, but not all.
2. Note which measures slice on the scheme; their values will rework.
3. Note manual attribute data in the affected range — the one non-regenerable asset.
4. Do one event first, verify slices/attributes/derived measures, then proceed.

See also#

• Designing an Event Scheme
• Time Slices and Event-Sliced Measures
• Forms and Data Capture
• Analysing Data by Event