Workflows

Customize incident phases, evidence handling workflows, and report templates to match your organization's processes.

Incident Phases (Lifecycle)

DFIRe comes with default incident phases based on NIST guidelines. You can customize these at Settings → Incident Lifecycle:

  • Add phases: Create additional phases for your process
  • Rename phases: Use terminology your team prefers
  • Reorder phases: Adjust the workflow sequence
  • Remove phases: Delete phases you don't use
  • Choose the resolving phase: Turn on Resolves the incident on the phase that resolves an incident. That phase and every phase after it count as resolved. See Resolving an incident

Important: Incident phases are dynamic: changes affect all incidents, including existing ones. Removing a phase leaves the incidents that were in it without a phase. Its playbook actions move to the Unassigned group, where you can put them on another phase. Configure your incident lifecycle before taking the system into production use.

Case Type Actions

Actions (task checklists) are defined per case type, not globally. Each case type can have its own set of actions assigned to specific phases. Actions come in two flavors:

  • Simple Actions: Stateful checklist items that move through Pending, Started, Blocked, Done, and Skipped states. Use these for straightforward tasks like “Isolate affected endpoints” or “Notify Legal”.
  • Workflows (Decision Trees): Guided decision trees that walk the responder through a series of true/false questions to determine the correct course of action. Use these for complex decisions that depend on multiple conditions, such as determining notification obligations or escalation paths.

Both types can be configured within Case Type templates:

  1. Configure phases first

    Ensure your incident phases are set up before defining actions, as each action is assigned to a phase.

  2. Go to Settings → Playbooks

    Select or create the case type you want to configure.

  3. Define actions for each phase

    Add simple actions or decision tree workflows that should appear when an incident of this type is created.

See Playbooks for details on configuring playbooks and their actions.

Tip: You can also export your settings to JSON via Settings → Global Settings → Data Portability → Export, edit the case type definitions in a text editor, and import the modified JSON back into DFIRe.

Report Templates

An administrator configures report sections once for the whole installation, under Settings → Reporting. For each section you can:

  • Define section headings and order
  • Include boilerplate content for each section
  • Add a writing guide for each section (helps analysts know what to include and serves as a reference for quality assurance)
  • Choose whether it appears in incident reports, investigation reports or both

See Reports for more on report generation.

Evidence Handling Workflow

The evidence handling workflow defines the states evidence items can move through (e.g., Collected, In Analysis, Returned). Like incident phases, this workflow is configured at Settings → Evidence Workflow.

Configure before production: Changes to the evidence handling workflow affect all evidence items. Set up your workflow states before the system is in production use.

Notifications

Notifications tell a user that something needs their attention. That can be a message to them, a change to their part in a case, or a significant change to a case they work on. Routine activity, such as a new note, new evidence or a new file, notifies nobody. The case timeline records it. DFIRe never notifies users about their own changes.

DFIRe notifies a user when:

  • Someone mentions them with @ in a note, a custody entry, the context of an indicator, a manual timeline entry or the case chat.
  • Someone replies to their message in the case chat.
  • Someone adds them to a case team, makes them lead investigator, changes their role on the team, or removes them from it.
  • Someone assigns an action to them, or unassigns it.
  • Someone else starts, blocks, unblocks, skips or completes their action, sets it back to not started, or changes its note or details.
  • Someone records a custody transfer of an evidence item to them.
  • A playbook they own is due for review.
  • DFIRe could not create the Slack channel of a case they lead, or a channel they asked for.

DFIRe notifies everyone assigned to the case, as lead investigator, investigator or viewer, when:

  • Someone acknowledges, closes, reopens or archives the case, or sets it back to New.
  • Someone changes its severity or priority, escalates it to an incident, or moves it to another phase.
  • The lead investigator changes.
  • Someone pauses or resumes the SLA timer, or starts or completes a compliance timer.
  • A compliance timer reaches half, a quarter or a tenth of its time remaining, or its deadline passes.
  • An incident SLA target becomes at risk or its deadline passes.
  • An indicator added to the case already appears in other cases. DFIRe also notifies the user who added it.
  • Someone deletes the case.

DFIRe notifies the lead investigator when:

  • Someone blocks an action in the case.
  • A Jira issue linked to the case stops syncing.
  • A Direct Storage file no longer matches its recorded SHA-256 when someone verifies it again. DFIRe also notifies the user who started the check.

The retention schedule archives and deletes cases without notifying anyone. A case with nobody assigned notifies nobody. A notification stays unread until the user marks it read.

DFIRe saves the error and warning messages it shows in the browser to the notification list, already marked read. The list keeps their full text.

The list shows only notifications about cases the user can open. When a user leaves a case team, the notifications about that case leave their list. Some notifications are about a case the user can no longer open, for example because they left the team or someone deleted the case. These show only the case number. DFIRe deletes read notifications after 14 days, and deletes the notifications of a deleted case.

Reading notifications

The notifications button in the header shows how many notifications are unread. Select it to open the list. Each entry shows the whole notification. Select an entry to mark it read. When a notification points somewhere, such as a note or an action, its button (for example Open notes) goes there and marks it read. At the bottom of the list, Mark all read marks every notification read, and Clear all deletes every notification at once.

When a notification arrives, DFIRe shows it in a pop-up message with an Open button and plays a short sound. A breached compliance timer or SLA target stays on screen until you close it. A chat mention does not pop up in a browser tab that already shows that chat.

Sound and desktop notifications

Set these per browser with the two buttons at the top of the notification list. A button is amber while its setting is on.

  • The speaker turns the sound on or off. The sound is on by default.
  • The bell turns desktop notifications on or off. A desktop notification shows while DFIRe is in the background. Turning them on asks the browser for permission. The notification says only "You were mentioned" or "You have a new notification". Select it to bring DFIRe to the front with the list open. If the browser cannot show them, the bell is unavailable, and pointing at it tells you why.

Both work only while a DFIRe tab is open. With several tabs open, one of them plays the sound. Desktop notifications need an HTTPS connection. On macOS, allow the browser itself under System Settings → Notifications. A Focus mode silences it.

Notification rules are built into the system and are not user-configurable. For external integrations, see Webhooks.