How to Forward and Triage Vendor Notification Emails with a Mailhook and AI

Point your vendor system emails at a Spojit Mailhook address, let an agent classify each one into a structured priority, log it as a Monday.com item, and post the urgent ones straight to Slack.

What This Integration Does

Vendors and supplier systems send a constant stream of notification emails: shipment delays, backorders, price changes, account alerts, and outage notices. Most of them are noise, but a handful are genuinely urgent and get lost in a shared inbox until it is too late. This workflow turns that inbox into a triaged queue. Every vendor email becomes a structured record with a priority you can trust, a tracked item on a Monday.com board, and a Slack ping for anything that needs a human now.

The workflow runs on a Spojit Mailhook trigger. You forward vendor mail (or set a vendor system to send) to a unique Spojit address, and each message starts a run within seconds. A Connector node in Agent mode reads the subject and body and returns a structured priority, category, and one-line summary. A Monday.com Connector node logs every message as a board item, and a Condition node posts only the urgent ones to Slack. Runs are independent and stateless: each email is handled on its own, deduplicated per message, and nothing about one email affects another. If the same vendor sends ten emails, you get ten runs and ten Monday.com items.

Prerequisites

  • A workspace where you can create workflows in the Spojit Workflow Designer.
  • A Slack connection (added under Connections → Add connection) with permission to post messages, plus the target channel's ID (for example C0123ABCD).
  • A Monday.com connection, plus the boardId of the board where vendor notifications will be logged. Note the groupId if you want items to land in a specific group.
  • The column IDs on that board for the fields you want to populate (for example a status column and a text column). You can read these with the Monday.com get-board tool.
  • A place to send the vendor mail: a forwarding rule on your inbox, or a vendor system where you can set the notification recipient address.

Step 1: Create the Mailhook trigger

Create a new workflow and open the Trigger node. Set Trigger Type to Mailhook. Optionally set an Address prefix (1 to 24 characters, default mh) such as vendors so the generated address is recognizable, then click Generate email address. Spojit produces a unique address like vendors-1a2b3c4d5e6f7g8h@mailhook.spojit.com. Copy it and point your vendor mail at it, either through an inbox forwarding rule or by setting it as the notification recipient in the vendor system.

To keep stray mail out, add an optional From allowlist with your vendor domains and an optional Subject regex. The trigger fires whether the address appears in To, Cc, or Bcc, and each message is deduplicated automatically. Downstream nodes read the email as {{ input }}, which exposes {{ input.subject }}, {{ input.text }}, {{ input.from }}, {{ input.replyTo }}, and {{ input.receivedAt }}.

Step 2: Classify the email with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode. This is where the intelligent layer reads the raw email and turns it into a decision. You do not need an external connector here: the agent works from your prompt and the email content. Give it a prompt that pins down exactly what to extract:

You are triaging a vendor notification email.

Subject: {{ input.subject }}
From: {{ input.from }}
Body:
{{ input.text }}

Classify this email. Return:
- priority: one of "urgent", "normal", or "low"
- category: one of "shipment_delay", "backorder", "price_change",
  "account_alert", "outage", or "other"
- summary: a single sentence a human can act on
Treat outages, shipment delays affecting open orders, and account
suspensions as "urgent".

Open the node's Response Schema and force structured JSON so downstream nodes can rely on the fields:

{
  "type": "object",
  "properties": {
    "priority": { "type": "string", "enum": ["urgent", "normal", "low"] },
    "category": { "type": "string" },
    "summary":  { "type": "string" }
  },
  "required": ["priority", "category", "summary"]
}

Set the node's Output Variable to triage. The result is then available as {{ triage.priority }}, {{ triage.category }}, and {{ triage.summary }}. Agent mode costs AI credits, so keep the prompt tight; see the linked article on Agent mode versus Direct mode if you are unsure when each fits.

Step 3: Log the email as a Monday.com item

Add a Connector node in Direct mode, select the Monday.com connector, and choose the create-item tool. This step runs for every email so you have a complete, searchable record. Map the inputs:

  • boardId: your vendor-notifications board ID.
  • name: a readable item title, for example {{ input.subject }}.
  • groupId (optional): the group to drop items into.
  • columnValues: a JSON object keyed by your board's column IDs.

The columnValues object uses Monday.com column IDs as keys. Replace the placeholders below with the IDs from your board (a status column and two text columns in this example):

{
  "status":        { "label": "{{ triage.priority }}" },
  "text_category": "{{ triage.category }}",
  "text_summary":  "{{ triage.summary }}"
}

Set the node's Output Variable to mondayItem so you can reference the new item if you extend the workflow later. If you are unsure of your column IDs, run get-board once and read them from the response before wiring this step.

Step 4: Branch on priority with a Condition node

Add a Condition node after the Monday.com step. Set the test to compare {{ triage.priority }} against the value urgent. The true output handles emails that need attention now; the false output ends the run quietly, since the Monday.com item already captured the record. This keeps Slack reserved for messages people actually need to see, instead of every routine notification.

Step 5: Post urgent emails to Slack

From the true branch of the Condition node, add a Connector node in Direct mode, select the Slack connector, and choose the send-message tool. Map the inputs:

  • channel: your alert channel ID, for example C0123ABCD.
  • text: a templated message built from the triage result.

A clear message ties the alert back to the vendor and the Monday.com record:

:rotating_light: Urgent vendor notification ({{ triage.category }})

{{ triage.summary }}

From: {{ input.from }}
Subject: {{ input.subject }}
Logged on the vendor board as item {{ mondayItem.id }}

If you want the message threaded under an existing announcement, set the optional thread_ts input to that message timestamp. For richer layout you can supply Block Kit blocks, but plain text is enough to get a reliable alert out the door.

Step 6: Acknowledge the sender (optional)

Mailhook runs are always asynchronous, so the sender never gets an automatic reply. If a vendor expects confirmation, add a Send Email node at the end of the run. Set Recipients to {{ input.replyTo }}, write a short Subject and Body confirming receipt, and leave the built-in mail service to send it. External recipients must be on your org allowlist under Settings → General → Email recipients. Save and enable the workflow when the branches look right.

Tips

  • Keep the agent prompt focused on classification only. The more narrowly you define the priority and category values, the more consistent the structured output and the fewer credits each run costs.
  • Use the From allowlist on the Mailhook trigger to ignore mail from outside your vendor domains, so spam never creates Monday.com items.
  • If a vendor sends both a confirmation and a follow-up under the same subject, the Mailhook still treats them as separate messages and deduplicates only true duplicates, so you will not lose the follow-up.
  • Store the Slack channel ID and Monday.com boardId as workflow variables if you reuse this pattern for several vendor boards, so each copy only needs those two values changed.

Common Pitfalls

  • Monday.com columnValues are keyed by column ID, not column title. Using the visible title silently drops the value; always read the IDs from get-board first.
  • Status columns expect a { "label": "..." } shape rather than a plain string, and the label must match an existing status option on the board exactly, including capitalization.
  • If the agent occasionally returns a priority outside your enum, the Condition node will treat it as not urgent. Keep the enum in the Response Schema so the output stays inside the values you branch on.
  • A Slack channel must be the channel ID, not the #name. If the connection has not been invited to a private channel, the message will fail; invite it first or use a public channel.
  • Mailhook stores received emails for 30 days only. This workflow does not retain the raw email itself, so the Monday.com item and Slack message are your durable record.

Testing

Before pointing real vendor mail at it, send a single test email to the generated Mailhook address from one of your allowlisted addresses, with a clearly urgent subject and body. Watch the run in the workflow's execution history: confirm the trigger fired, the agent's triage output has the expected priority, the Monday.com item appears on the board with the right column values, and (because it is urgent) the Slack message lands in your channel. Then send a clearly routine email and confirm it creates a Monday.com item but does not post to Slack. Once both paths behave, add the forwarding rule or set the vendor system recipient 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.