How to Index Incident Postmortems into a Searchable Knowledge Collection

Forward finished incident postmortems to a Spojit Mailhook address, fetch the attached PDF or Markdown bytes with an Attachment node, embed them into a persistent incident-knowledge collection with a Knowledge node in Embed mode, and confirm indexing back to the author with a Send Email reply.

What This Integration Does

Every incident your team resolves produces a postmortem, and most of those documents end their life buried in a chat thread or a personal drive folder where no one finds them six months later. This Spojit workflow turns the act of "sharing the finished writeup" into the act of "permanently indexing it." An engineer (or your incident-management tool) simply emails the completed postmortem to a dedicated Mailhook address, and Spojit fetches the attached file, embeds it into a long-lived Knowledge collection that any future workflow can query, and emails a confirmation back so the author knows the document is now searchable.

The run is push-based: a Mailhook trigger fires within seconds of mail arriving, with no mailbox or polling involved. The trigger exposes the parsed message as {{ input }}, the Attachment node pulls the real bytes of the matching file, the Knowledge node in Embed mode writes those bytes into a persistent collection (returning a chunk count), and a Send Email node replies to the original sender. Each email is deduplicated per message, so a forwarded duplicate will not double-index. Because the collection is persistent and workspace-scoped, the indexed knowledge accumulates over time and survives across runs, ready to be queried by Miraxa or a separate lookup workflow.

Prerequisites

  • A workspace where you can create workflows in the Spojit Workflow Designer.
  • A persistent Knowledge collection to hold the archive. Create one ahead of time in the Knowledge section of the sidebar with New Collection (for example, name it Incident Postmortems). The embedding model is fixed at creation, so pick it now and keep it consistent.
  • Agreement on what authors will send: a single postmortem file per email, exported as PDF or Markdown. Both formats are supported document types in the Knowledge node.
  • The sender addresses (or domains) you want to accept, if you plan to use the Mailhook From allowlist filter.
  • Each author's email address on your org allowlist under Settings → General → Email recipients, so the Send Email confirmation can reach them.

Step 1: Create the Mailhook trigger and generate an address

Add a Trigger node and set Trigger Type to Mailhook. Optionally set an Address prefix (1 to 24 characters, default mh) such as postmortems, then click Generate email address. Spojit produces a unique address in the form postmortems-<random16>@mailhook.spojit.com. Copy it and share it with your engineers, or point your incident tool's "send report to" rule at it. Any mail to that address starts a run within seconds; no mailbox or OAuth is involved. To accept reports only from your team, set a From allowlist, and optionally add a Subject regex such as (?i)postmortem|incident so unrelated mail is ignored. The trigger output is available downstream as {{ input }}, including {{ input.subject }}, {{ input.from }}, {{ input.replyTo }}, and {{ input.attachments }}.

Step 2: Fetch the postmortem file with an Attachment node

Add an Attachment node directly after the trigger. The designer only allows this node when the workflow uses a Mailhook trigger, so add it after Step 1. Set Mode to Single so you get the first matching file as one object. To accept both export formats, set the Content type filter to application/pdf, text/markdown, or use a Filename pattern glob like *.pdf if your team standardizes on PDF. Turn on Fail if no attachment matches so an empty email surfaces as a clear failure rather than silently embedding nothing. The node output in Single mode looks like this:

{
  "filename": "incident-2026-06-12-checkout-outage.pdf",
  "contentType": "application/pdf",
  "size": 184213,
  "content": "<base64-encoded bytes>"
}

The content field holds the base64 bytes you will hand straight to the Knowledge node. Keep each file under the 10 MB per-attachment limit; received emails are retained for 30 days.

Step 3: Derive a stable file name for the document

Add a Transform node to build the name the document will carry inside the collection. The Knowledge node overwrites an existing document if you reuse its name, so a deterministic name turns re-sending a corrected postmortem into a clean replacement instead of a duplicate. A simple, predictable choice is the attachment's own filename, available as {{ attachment.filename }}. If you prefer to key on the email subject instead, you can slugify it: add a Connector node in Direct mode on the text connector and call slugify with {{ input.subject }} as the input, producing a value like checkout-outage-rca-2026-06-12. Either way, carry the chosen value forward as the file name for the next step.

Step 4: Embed the document into the persistent collection

Add a Knowledge node and set its mode to Embed. Configure it as follows:

  • Collection: select your persistent Incident Postmortems collection (not Transient), so the document is added to the long-lived archive.
  • File Name: the stable name from Step 3, for example {{ attachment.filename }}. Reusing an existing name overwrites that document in place.
  • Document Type: choose PDF or Markdown to match what was sent. If your team mixes formats, branch on {{ attachment.contentType }} with a Condition node and use one Knowledge node per type.
  • Document Input: the base64 bytes from the Attachment node, {{ attachment.content }}.
  • Output Variable: name it embed_result. It returns the chunk count and metadata for the indexed document.

On a successful run the document is permanently part of the collection and immediately available to any workflow that queries it in Query mode. The embedding model used here is the one fixed when the collection was created, which is why consistency matters: always embed and query a collection with the same model.

Step 5: Confirm indexing back to the author with a Send Email node

Add a Send Email node so the person who sent the report knows it is now searchable. Because a Mailhook trigger sends no response to the original sender, this reply is how the author gets closure. Set Recipients to {{ input.replyTo }} (the address that sent the postmortem), set Subject to something like Indexed: {{ input.subject }}, and use a Body that reports the result:

Your postmortem "{{ attachment.filename }}" has been added to the
incident knowledge archive in Spojit.

Document chunks indexed: {{ embed_result.chunkCount }}

It is now searchable by the team.

Set If sending fails to Continue anyway so a confirmation problem never undoes a successful index. Remember that only upstream variables resolve in the body, and that external recipients must be on the org allowlist under Settings → General → Email recipients. This node uses Spojit's built-in mail service and counts toward your monthly email allowance.

Step 6: Save, enable, and route reports to the address

Save the workflow and enable it. Distribute the Mailhook address to your team, or set a forwarding rule in your incident tool so completed reports are emailed there automatically. If you ever need to retire the address (for example after a leak), open the trigger and use Regenerate address; the old address dies instantly and a new one is generated. You can scaffold this entire workflow by asking Miraxa, the intelligent layer across your automation, something specific like: "Build a workflow with a Mailhook trigger, an Attachment node in Single mode for PDFs, a Knowledge node in Embed mode that writes to my Incident Postmortems collection using {{ attachment.content }}, and a Send Email node back to {{ input.replyTo }}." Then fine-tune each field in the properties panel.

Tips

  • Keep one postmortem per email. The Attachment node in Single mode takes the first match, so a multi-file email would only index one document. If authors routinely attach several files, switch the node to Multiple mode and add a Loop node over {{ attachment.attachments }}, embedding each file in turn.
  • Use the same embedding model for the whole life of the collection. A later workflow that queries this archive must use the same collection, which guarantees the right model is applied.
  • Include the incident date in the file name (via the subject slug in Step 3) so future queries can be filtered by time and so corrected reports overwrite cleanly instead of piling up.
  • Watch the size limits: 10 MB per attachment and 25 MB per run by default. Ask authors to export text-only PDFs rather than image-heavy exports where possible.

Common Pitfalls

  • Adding the Attachment node without a Mailhook trigger. The designer refuses to save it, so set up the Mailhook trigger first.
  • Leaving Fail if no attachment matches off. An email with no qualifying file would otherwise run to completion having embedded nothing, and the author would still get a confirmation. Turn it on so empty submissions fail loudly.
  • Choosing a Transient collection in the Knowledge node. Transient collections are auto-cleaned at the end of the run, so the postmortem would vanish. This archive must use a persistent collection.
  • The confirmation email bouncing because the author's address is not on the org allowlist. Add sender domains under Settings → General → Email recipients before going live.
  • Re-sending a corrected postmortem under a new file name. That creates a second document instead of replacing the first. Keep the file name deterministic (Step 3) so corrections overwrite.

Testing

Before announcing the address to your whole team, test on a single document. Create a throwaway persistent collection (or use a clear test name), point the workflow at it, and email one small PDF postmortem to the Mailhook address from an allowlisted account. Open the run in execution history and confirm the Attachment node returned a non-zero size, the Knowledge node's embed_result shows a sensible chunkCount, and you received the confirmation email. Then open the collection in the Knowledge sidebar and verify the document appears in the table with a READY status. Once that single round trip works end to end, switch the Knowledge node back to your real Incident Postmortems collection and enable the workflow.

Learn More

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.