How to Post New High-Value Deals to Slack with AI Deal Summaries

Build a Spojit workflow that catches each new or advanced pipeline deal, gates on a value threshold, writes a two-line deal brief with an Agent-mode Connector node, and posts it to your deals channel in Slack with a triage reaction.

What This Integration Does

Sales teams drown channels with every deal update, so the ones that matter get lost. This workflow does the opposite: it listens for deal events pushed from your pipeline, keeps only the deals above a dollar threshold you choose, and posts a short, human-readable brief to a single Slack channel. Reps and managers see exactly who, what, and why it matters without opening the CRM, and the channel stays quiet enough that a notification actually means something.

A Webhook trigger receives an HTTP POST whenever a deal is created or moved a stage, pushed either by a Monday.com automation or by your CRM calling Spojit through the http pattern. a Connector node on the math connector normalizes the deal value, a Condition node drops anything under threshold, a Connector node in Agent mode drafts the brief from real deal fields, and the slack connector posts it and adds a reaction. The workflow is stateless and runs once per event, so a replayed or duplicate webhook simply produces another run; enable the webhook event-id dedup header if your source can send one.

Prerequisites

  • A Slack connection authorized to your workspace, with the bot invited to your deals channel. You need the channel ID (the C... string in the channel details), not just its name.
  • A signing connection for the Webhook trigger. Use the Spojit scheme if Spojit signs the request, the Slack scheme for Monday-driven setups that you sign yourself, or Custom for your CRM's own HMAC. See Setting Up a Webhook Connection.
  • If your deal events come from your CRM rather than Monday.com, the ability to register an outbound webhook (or a small http call) that POSTs JSON to the workflow URL. See How to Connect to Any REST API Using HTTP Requests.
  • A decision on your value threshold (for example 25000) and the currency your pipeline reports in.

Step 1: Receive the deal event with a Webhook trigger

Add a Trigger node and set Trigger Type to Webhook. Attach your signing connection so Spojit verifies each request by HMAC. Save the workflow to reveal its webhook URL, then register that URL with your source. For Monday.com, create a board automation ("When an item is created" or "When a status changes to Won-track") that sends a webhook. For a CRM, point its deal webhook (or an http http-post call) at the same URL.

The trigger output is the parsed JSON body, available as {{ input }}. Standardize the payload your source sends so later steps can rely on stable field names, for example:

{
  "dealId": "DEAL-4821",
  "name": "Acme Corp - Platform Renewal",
  "stage": "Negotiation",
  "amount": "48,500",
  "currency": "USD",
  "owner": "Priya Nair",
  "accountIndustry": "Logistics",
  "closeDate": "2026-07-15",
  "notes": "Expanding from 2 sites to 9; budget approved by CFO."
}

The Webhook trigger returns 202 with an executionId to the caller immediately; all real work happens asynchronously in the steps below.

Step 2: Normalize the deal value with the math connector

Incoming amounts are messy: "48,500", "$48500", or a number. Add a Connector node on the math connector in Direct mode and pick the calculate tool to coerce the value into a clean number you can compare. First strip non-numeric characters with a text replace step if your source sends formatting, then feed the result into calculate.

A simple pattern: use text replace to remove commas and currency symbols from {{ input.amount }}, store it as {{ amountClean }}, then call calculate with an expression that just echoes the number so the output is typed numerically:

{
  "expression": "{{ amountClean }}"
}

Bind the result to {{ dealValue }}. If your source already sends a numeric amount, you can skip the text step and pass it straight into calculate. Keeping a dedicated math step here means your threshold check compares numbers, never strings.

Step 3: Gate on the threshold with a Condition node

Add a Condition node so only high-value deals continue. Set the condition to compare {{ dealValue }} against your threshold, for example {{ dealValue }} is greater than 25000. Connect the true branch to the rest of the workflow; leave the false branch unconnected so smaller deals end the run quietly with no Slack noise.

If you want a second gate, add an extra check on the same node (for example stage equals Negotiation or Proposal) so early-stage deals do not alert until they advance. Routing the noise out here, before any AI step, also means you never spend AI credits summarizing a deal that would not be posted anyway.

Step 4: Write the deal brief with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode. Agent mode lets the agent reason over the deal fields and produce clean prose, and the Response Schema forces a predictable JSON shape so the next step can map fields reliably. Ground the prompt strictly in the values you already have so the brief never invents details:

Write a two-line deal brief for a sales Slack channel.
Line 1 (who/what): the account name, the deal stage, and the value.
Line 2 (why it matters): one sentence of business context.
Use ONLY these fields. Do not infer anything not present.

name: {{ input.name }}
stage: {{ input.stage }}
value: {{ dealValue }} {{ input.currency }}
owner: {{ input.owner }}
industry: {{ input.accountIndustry }}
closeDate: {{ input.closeDate }}
notes: {{ input.notes }}

Set a Response Schema so the output is structured rather than free text:

{
  "type": "object",
  "properties": {
    "headline": { "type": "string" },
    "why": { "type": "string" }
  },
  "required": ["headline", "why"]
}

Bind the result to {{ brief }}. Because the prompt names the exact fields and forbids inference, the summary stays anchored to the real deal record. Direct mode would not help here: there is no single tool that "writes a brief," so Agent mode is the right choice for this judgment step.

Step 5: Post the brief to Slack with send-message

Add a Connector node on the slack connector in Direct mode and pick the send-message tool. Set channel to your deals channel ID (the C... value) and compose text from the structured brief plus a link back to the deal:

{
  "channel": "C0123ABCDEF",
  "text": ":moneybag: *{{ brief.headline }}*\n{{ brief.why }}\nOwner: {{ input.owner }}  |  Stage: {{ input.stage }}  |  Value: {{ dealValue }} {{ input.currency }}"
}

The text field is what reps read, so keep it tight: the AI headline, the why line, then a compact metadata row. send-message returns the posted message's ts (its timestamp) in the result; bind the node's output to {{ posted }} so the next step can react to that exact message. If you prefer richer layout, send-message also accepts a blocks array, but plain text is enough for a clean two-line brief.

Step 6: Add a triage reaction with add-reaction

Add one more Connector node on the slack connector in Direct mode with the add-reaction tool, so the team has a built-in triage marker on the new message. Pass the channel ID, the timestamp from the previous step, and an emoji name without colons:

{
  "channel": "C0123ABCDEF",
  "timestamp": "{{ posted.ts }}",
  "name": "eyes"
}

A reaction such as eyes signals "needs a look," and reps can swap it for white_check_mark once a deal is claimed, giving you lightweight triage without a separate tool. If your source can fire follow-up events, you could later add a reaction change when a deal moves to Won, but the single reaction is the minimum useful triage signal.

Tips

  • Keep the AI step cheap by gating first: the Condition node in Step 3 sits before the Agent-mode Connector node, so only deals worth alerting on ever cost AI credits.
  • Store the channel ID, not the channel name, in send-message. Names can change; IDs are stable. Look it up once and reuse it.
  • For a sharper threshold, drive it from data instead of a constant: use the math percentage tool against an average deal size if you want "top X percent" rather than a fixed dollar figure.
  • To reply in a thread on a related earlier post, pass thread_ts to send-message; otherwise each deal posts as its own top-level message, which is usually what you want for triage.

Common Pitfalls

  • Comparing strings, not numbers. If you skip the math normalization in Step 2, "9,000" > 25000 can behave unexpectedly. Always feed {{ dealValue }} (a real number) into the Condition node.
  • Webhook replays. A retrying source can POST the same deal twice, producing two Slack posts. Turn on the trigger's event-id dedup header and have your source send a stable id per event.
  • Ungrounded summaries. If the Agent prompt is vague, the brief may invent figures. Name every field explicitly and add "Do not infer anything not present," as in Step 4.
  • The bot is not in the channel. send-message fails if the Slack app has not been invited to the target channel. Invite it before going live, and confirm the channel ID matches.

Testing

Before enabling the trigger live, post a single test event. Send one sample JSON body to the webhook URL (or fire one Monday.com automation on a test item) with an amount just above your threshold, then open the run in execution history and confirm: the math step produced a numeric {{ dealValue }}, the Condition node took the true branch, the Agent-mode Connector node returned a clean headline and why, and the Slack message and reaction appeared in your channel. Then send one below threshold and confirm the run ends with nothing posted. Once both behave, point your real pipeline at the workflow.

Learn More

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