# Triage an incident report and close it with sign-off
A safety report or service request lands in a shared inbox. Urgent work needs an immediate owner, while routine work can wait in a visible queue. Doing that by memory means urgent reports wait and closures happen without review.
Good for
Operations, facilities, and support teams tracking incidents or service cases
Level
Advanced
## What you'll build
One report form feeds one workflow. A [Switch](/documentation/flowcrafter/nodes/logic/switch/) routes by severity: urgent cases alert the on-call lead, high cases go to the response team, and everything else enters the daily digest. For urgent and high cases, the owner submits a closure request and a supervisor must approve it before the case is marked closed.
```mermaid
flowchart TD
A[Incident form submitted] --> B{Route by severity}
B -->|Urgent| C[Set status: Escalated]
B -->|High| D[Set owner: Response team]
B -->|Default| E[Set status: In queue Include in digest: Yes]
C --> F[Email on-call lead: closure form link]
D --> G[Notify response team: closure form link]
E --> H[Daily digest]
F --> R[Wait for Form Submission: closure request]
G --> R
R -->|Submitted| I[Wait for Approval: supervisor closure review]
R -->|Expired| L
I -->|Approved| J[Set status: Closed]
I -->|Rejected| K[Email the owner: what still needs doing]
I -->|Expired| L[Escalate closure to the safety lead]
J --> M[Send Email: reporter with the outcome]
```
## Before you build
- Define the allowed severity values and who owns each category.
- Add administrative **Case status**, **Owner**, and **Include in digest** fields.
- Create a separate closure-request form with a hidden `key` field and a required resolution-summary field.
- Choose monitored addresses for on-call, response-team, supervisor, and expiry messages.
- Decide what evidence a supervisor needs before approving closure.
## Build it step by step
1. Build an incident form with a **Severity** field and incident description. Add administrative-only **Case status**, **Owner**, and **Include in digest** fields.
2. Build a **Closure request** form with a required resolution summary. Add a hidden field, enable dynamic population, and set its parameter name to `key`.
3. Open the incident form and click **Workflows** in the form toolbar. Click **New Workflow**, then **Add Trigger** and choose [Form Submitted](/documentation/flowcrafter/nodes/triggers/form-submitted/).
4. Add Switch named **Route by severity**. Add `Urgent` first and `High` second, each comparing the submitted Severity field to that exact saved value. Everything else falls to **Default**.
5. On **Urgent**, use [Update Entry Field](/documentation/flowcrafter/nodes/actions/update-entry-field/) to set **Case status** to `Escalated` and **Owner** to `On-call lead`. Send that owner the incident details and a closure link such as `https://your-site.test/close-incident/?key={{run.key}}`, replacing the domain and path with the real page.
6. On **High**, set **Case status** to `Assigned` and **Owner** to `Response team`, then send the same kind of closure link with [Send Notification](/documentation/flowcrafter/nodes/actions/send-notification/) or [Send Email](/documentation/flowcrafter/nodes/actions/send-email/).
7. Join Urgent and High at [Wait for Form Submission](/documentation/flowcrafter/nodes/flow/wait-for-form-submission/) named **Wait for closure request**. Choose the Closure request form, match its hidden key to `{{run.key}}`, and set **Expiry** (hours) to the case deadline. Connect **Expired** to the safety-lead escalation.
8. On **Submitted**, add [Wait for Approval](/documentation/flowcrafter/nodes/flow/wait-for-approval/) named **Closure review**. Address the supervisor, include the closure entry's resolution summary, require a rejection note, and set **Expiry** (hours) plus reminders.
9. On **Approved**, set **Case status** to `Closed`, set **Include in digest** to `No`, and email the reporter. On **Rejected**, email the owner with `{{ "Closure review".note }}`. On **Expired**, escalate to the safety lead.
10. On Switch **Default**, set **Case status** to `In queue` and **Include in digest** to `Yes`.
:::tip[Route richer than severity]
Use [GP Advanced Conditional Logic](https://gravitywiz.com/documentation/gravity-forms-advanced-conditional-logic/) when a case needs nested groups, user-aware rules, or date comparisons.
:::
## Data passed between nodes
| From | Data used later | Where it goes |
|---|---|---|
| Form Submitted | Severity, category, description, reporter email, and entry identity | Switch, owner update, and messages |
| Route by severity | One selected output | Urgent, High, or Default path |
| Run context | `run.key` | Closure-form URL and Wait for Form Submission match |
| Wait for closure request | Closure entry `entry_id` and form identity | Closure review input |
| Closure review | `action`, `note`, `resolved_by`, `resolved_at` | Status update, rework message, and run history |
## Edge cases
- The Switch takes only the first match. Keep urgent cases first and preserve Default.
- The run key matches a closure request to the incident but does not prove who submitted it. Put the closure form behind authentication when identity matters.
- Low-severity cases stop at `In queue`; another workflow or staff action must later assign and close them.
- Approval expiry advances only approvals parked after expiry scheduling is available; older already-waiting approvals need manual attention.
## Test and activate safely
New workflows start **Inactive**. Use builder tests for every severity value and an unknown value. Then temporarily activate on staging or with test inboxes for controlled live runs so Urgent and High entries create parked waits; submit closure requests with matching and nonmatching keys. Builder tests cover approval and rejection, while closure and approval expiry need those real parked runs and short deadlines. Restore production values, activate only after Default and both Expired routes reach monitored inboxes, and inspect the first run in each severity branch.
## What Flowcrafter adds
A notification can tell someone a report arrived. Flowcrafter makes triage a process: exactly one severity branch wins, the case's owner and status are written where staff can see them, urgent cases jump the queue, and nothing closes without a recorded decision. Every step — routing, reminder, approval — stays in one run's history, which is the audit trail an incident process needs.
The same shape fits fault tickets, maintenance requests, compliance reports, and service cases of every kind.
## Related resources
- [Switch](/documentation/flowcrafter/nodes/logic/switch/) — first-match severity routing with a Default branch
- [Update Entry Field](/documentation/flowcrafter/nodes/actions/update-entry-field/) — keep case status and owner on the entry
- [Wait for Form Submission](/documentation/flowcrafter/nodes/flow/wait-for-form-submission/) — resume only for the matching closure request
- [Wait for Approval](/documentation/flowcrafter/nodes/flow/wait-for-approval/) — closure sign-off with notes and expiry