Incident Review Workflow — From Draft to NERIS Submission

Every incident in Command Established follows a structured review process. For departments enrolled in NERIS (National Emergency Response Information System), the review process ensures data quality before federal submission. Even without NERIS, the workflow provides a structured path from initial entry through supervisor approval. This guide explains each stage, who can do what, and how incidents move through the lifecycle.

The Review Lifecycle at a Glance

Incidents progress through these statuses:

Draft → Ready for Review → Under Review → Approved → (NERIS submission) → Locked

At each stage, specific roles control what happens next. The system enforces these rules — you'll only see status options in the dropdown that are valid for your role and the incident's current state.

Roles in the Review Process

Three levels of authority govern who can perform each transition:

• Author — The person who created the incident, anyone assigned to it, or any member with the update:incident permission. Authors handle the initial work: filling in details, submitting for review, and responding to feedback.
• Reviewer — Department admins, owners, or any member with the update:incident-review permission. Reviewers evaluate submitted incidents, approve them, or return them for corrections.
• Admin — Department admins and owners only. Admins handle sensitive operations like unlocking incidents that have already been reported to NERIS.

Tip: You can grant review permissions to specific members through Settings → Permissions & Groups without making them a full admin.

Reviewers see review actions in the incident header — Start Review while it's awaiting review, a single Review action while it's under review (a dialog where you choose between approving or returning it to the crew with a reason), Lock once approved, and (when they also hold the NERIS submission permission) Submit to NERIS. Reviewers without edit access get the same actions on a read-only view of the full report; reviewers with edit access get them in the incident's edit view.

Status-by-Status Walkthrough

Draft

Every incident starts as a draft. This is where responders fill in the details — incident type, address, apparatus, timeline, and any other relevant information.

Who can edit: The incident creator, assigned members, or anyone with update:incident permission.

What happens next: When the incident is ready, the author sets the status to Ready for Review. For departments with NERIS configured, the system checks that all NERIS-required fields are filled in before allowing this transition:

• Incident type
• Street address, city, and postal code
• Received time
• At least one apparatus (POV personnel alone don't count — NERIS requires formal apparatus unit responses)

If anything is missing, a checklist appears showing exactly which fields need attention, with links to jump directly to the right section of the form.

Ready for Review

The incident has been submitted by its author and is waiting for a reviewer to pick it up. The author can still pull it back to Draft if they realize something needs to change.

Who can act:

• Author → pull back to Draft
• Reviewer → move to Under Review

Under Review

A reviewer is actively evaluating the incident. They'll check the details for accuracy, completeness, and compliance with reporting requirements. Because the crew can still edit the incident while it's under review, approval re-runs the same NERIS-readiness check as submission — if required fields were removed mid-review, the reviewer sees the missing-field checklist instead of approving an incomplete record.

Who can act (reviewer only):

• Approve → move to Approved (the incident is ready for NERIS submission)
• Return → move to Returned with a required reason explaining what needs to be fixed

Returned

The reviewer found issues and sent the incident back with a reason. A banner at the top of the incident displays the return reason so the author knows exactly what to fix.

Who can act:

• Author → once corrections are made, move back to Draft to restart the review cycle

Note: Returned incidents go back to Draft, not directly to Ready for Review. This is intentional — it gives the author a chance to make corrections and re-verify the NERIS readiness checklist before resubmitting.

Approved

The incident has passed review. From here, a reviewer can either submit to NERIS (which automatically locks the incident) or manually lock it to finalize the record without federal submission.

Who can act:

• Reviewer → submit to NERIS (via the NERIS tab), which automatically locks the incident
• Reviewer → manually lock via the status dropdown (for incidents that don't need NERIS submission)

Locked

A locked incident's core fields (basic info, address, apparatus, timeline) cannot be edited, protecting the integrity of finalized or federally-reported data. An incident becomes locked in one of two ways:

• Automatically when submitted to NERIS — the system locks it immediately after a successful submission
• Manually by a reviewer via the status dropdown — for incidents that don't need NERIS submission but should still be finalized

If an admin unlocks an incident that has been submitted to NERIS, saving any changes will show a confirmation dialog warning that the local record will differ from the federal report until a reviewer pushes an update.

What can still be edited on a locked incident:

• Fire Investigation — Investigation details, cause determination, evidence tracking, and related findings can be added or updated at any time, since investigations often continue well after an incident is reported.

Who can act:

• Admin/Owner only → unlock back to Approved (this is deliberately restricted because unlocking reopens a record that may already be in the federal system)

Why is unlocking admin-only? Once an incident is submitted to NERIS, changes have real consequences — the federal record may need to be corrected too. Unlocking is restricted to admins and owners to prevent accidental modifications to reported data. Once unlocked, the incident follows the normal editing rules again, so the crew that responded can make the corrections themselves (see "Correcting a Reported Incident" below).

NERIS Submission

NERIS submission is not automatic — it's a deliberate, user-initiated action. Approving an incident does not send it to NERIS; a reviewer must explicitly navigate to the NERIS tab and click the submit button. This gives departments full control over when data is sent to the federal system.

Once an incident is approved, the NERIS tab shows a submission panel. Clicking Submit to NERIS sends the incident data to the federal system and automatically locks the incident.

After submission:

• The NERIS tab displays the assigned NERIS ID (format: FD... | ...)
• The submit button changes to Push Update to NERIS for future updates
• A diff view shows any differences between your local data and what NERIS has on file

Correcting a Reported Incident

Sometimes you need to correct an incident that has already been reported to NERIS. Because a push rewrites the federal record, it always requires review authority and a documented reason.

Here's how the process works:

1. Unlock — An admin unlocks the incident (Locked → Approved). The incident now follows the normal editing rules again.
2. Make the changes — The crew (or anyone who can normally edit the incident) makes the necessary field edits and saves. The NERIS tab shows a diff of what changed compared to the federal record.
3. Push the correction — A reviewer opens the NERIS tab and clicks Push Update to NERIS. A dialog asks for a reason explaining why the reported data is being corrected — this is required.
4. Re-lock — On a successful push, the incident automatically locks again, so the local record and the federal record finalize together.

The stated reason is stored with the incident and preserved in its audit trail, alongside who made each edit and who pushed the update — documenting the full history of what changed in the federal record, who changed it, and why.

Common Workflows

Standard Incident Flow

1. Responder creates incident and fills in details
2. Responder sets status to Ready for Review
3. Officer/reviewer moves to Under Review, checks details
4. Officer approves → incident moves to Approved
5. Officer submits to NERIS from the NERIS tab → incident auto-locks

Incident Needs Corrections

1. Reviewer moves incident to Under Review
2. Reviewer finds issues → opens Review and chooses Return to Crew with a reason
3. Author sees the return reason banner, makes fixes
4. Author moves back to Draft, then resubmits as Ready for Review
5. Reviewer re-reviews and approves

Post-Submission Correction

1. Incident is locked after NERIS submission
2. Someone notices an error in the reported data
3. Admin unlocks the incident (Locked → Approved)
4. The crew makes the field corrections and saves
5. A reviewer clicks Push Update to NERIS, enters the reason for the correction
6. The corrected data is pushed to NERIS and the incident automatically re-locks

Summary of Transitions