Before
An analyst monitored the reporting inbox, reviewed messages one by one, and selected qualifying reports for triage. They also had to identify and exclude messages sent by the reporting mailbox to avoid reprocessing internal responses or notifications.
How it works
- Start an intake run and read the reporting inbox for the polling window.
- Exclude messages sent by the reporting mailbox so only external reports remain.
- Send each remaining report individually to phishing analysis and return the processing results.
Workflow details
- Intake: A secure webhook invocation starts a run that reads the reporting inbox for the configured polling window, bringing reported messages into the workflow.
- Self-message filter: The flow compares each sender with the designated reporting mailbox and removes messages originating from that mailbox, preventing responses or notifications from being reprocessed.
- Triage handoff: Every remaining report is sent individually to the phishing analysis workflow, creating a clear one-report-at-a-time handoff.
- Controlled processing: Reports are handled sequentially, and the parent flow stops if the analysis handoff fails rather than silently skipping a report.
- Result: The flow returns the number of reports sent and their analysis outcomes, giving the SOC a consistent intake record for the polling cycle.
What changed
Mailbox intake, self-message filtering, and report handoff now happen automatically in one controlled run. Each qualifying report is passed to analysis sequentially, and the SOC receives a count and outcome record instead of performing the handoff manually.
Work removed
Reviewing the reporting inbox, identifying qualifying messages, excluding self-generated messages, selecting reports for triage, and forwarding each report to the phishing analysis workflow.
Expected outcome
For each run with reports, one recurring inbox-review and filtering cycle is removed, along with one manual triage handoff per qualifying report.
