Download all docs

Recipe: Multichannel Inbox

This recipe collects messages from every channel your team uses into one board. A slack, discord, teams, and email connector each receive inbound messages, and every one becomes a card on a single kanban board — so support, sales, or ops triage one queue instead of four apps.

The problem it solves

Conversations are scattered across Slack, Discord, Teams, and email, and nobody owns “all of it”. Things fall through the cracks because there is no shared queue and no shared state. This recipe fans every channel into one board where each message is a trackable card with a column, an assignee, and an action — one place to triage, with state everyone can see.

Elements

ElementRole
slackReceives inbound Slack messages.
discordReceives inbound Discord messages (Gateway listener).
teamsReceives inbound Microsoft Teams activity.
emailReceives inbound email.
boardOne kanban board where every message becomes a card.
automationNormalizes each inbound event into a card.

Flow

  1. Create a board. It is a generic kanban with columns, a configurable card schema, and card actions — model columns like New → In progress → Done and add the fields you triage on.
  2. Create your inbound connectors. Each is a bidirectional element that receives when its trigger port is left unwired: slack (Events API listener), discord (Gateway listener), teams (its events webhook receiver, which emits teams.activity.received), and email (inbound via the platform mailbox or external IMAP — list-inbox, get-message, unread-count).
  3. For each inbound message, create a card on the board with the board’s add-card operation, carrying the sender, channel, and body as card metadata. Several channels writing into the one board is the fan-in.
  4. Triage on the board: move cards with update-card, read them with get-card / list-cards, and trigger per-card workflows with run-card-action. Get a roll-up with board-summary.
  5. Drive the normalization with an automation, which references slack, discord, teams, email, and (through its step graph) the board — so each inbound event maps to one add-card call regardless of which channel it came from.

What this shows

Every chat connector on the platform shares the same receive/send duality, so four very different services — Slack, Discord, Teams, email — funnel into one queue through the same pattern: leave the trigger port unwired, map the inbound event to an add-card. The board gives the merged stream what a raw firehose lacks — columns, assignees, a card schema, and actions — turning “messages from everywhere” into a triage surface with shared state. Adding a fifth channel is the same three moves, not a new architecture.

Next pages