Quarantine: the user flow

Seed text for the Quarantine Help record.

What it is

Rows the system could not attribute to exactly one cycle, each kept with a reason class until the cause is fixed.

When records appear (what a run is)

A run is never a user upload, and there is no start-run button for tenant users. Records arrive from two sources:

The company backfill when a tenant is switched onto cycles, and any later re-run. Evercomm runs it.
Everyday writes afterwards (data entry, imports, integrations) when a row does not resolve to exactly one cycle.

The flow

System

Admin

1 · Run executes
The company backfill at switch-on, a later re-run, or everyday writes afterwards.

2 · Refused rows are parked
Every row the rules refuse to place gets a quarantine record: the run id, the row, a reason class, and candidate cycles where they exist.

3 · Tab shows the backlog
Per-run, per-reason counts; the tab badge carries the open total.

6 · Re-run
Evercomm runs a company backfill re-run after the fix.

7 · Rows re-resolve
Rows whose cause is fixed clear; the rest stay listed with their reasons.

4 · Admin reads the reason
Opens a record; the reason is plain terms: no matching cycle, several candidates, year disagreement, and so on.

5 · Fixes the cause at the source
A data value or the organization setup. Quarantine never edits reported numbers directly.

The tab itself is drawn on the Quarantine tab wireframe.

Scope and cycle linkage

Only tenants with Reporting Cycles switched on run this or see the tab. The backfill attributes their existing framework data; it never creates GRI cycles. Records link back through their run; many rows are quarantined precisely because no single cycle could be resolved, which is why the tab sits at area level with a run filter rather than inside one cycle, and cycle detail links in pre-filtered.