Communication Triggers

Communication triggers turn provider messages into one normalized workflow payload.

Provider tags

<slack id="slackAgent" events="app-mention,direct-message" channels="support" bot-token="{{secrets.SLACK_BOT_TOKEN}}" app-token="{{secrets.SLACK_APP_TOKEN}}" />
<telegram id="telegramAgent" events="message" bot-token="{{secrets.TELEGRAM_BOT_TOKEN}}" />
<discord id="discordAgent" events="app-mention,direct-message" bot-token="{{secrets.DISCORD_BOT_TOKEN}}" />

WhatsApp uses events="message", a Phone Number ID, verify token, and app secret. Provider setup is documented under Communication Overview.

Normalized payload

Scripts read provider-independent fields such as provider, event, text, senderId, conversationId, messageId, threadId, and occurredAt from context.payload.

Raw envelopes, signatures, headers, credentials, and complete provider profiles do not enter workflow context. WOML ignores supported bot/self messages and non-message provider events where applicable.

Build provider-independent agent logic

A normalized message lets the same business step work across providers:

<triggers>
  <telegram id="telegramMessage" events="message" bot-token="{{secrets.TELEGRAM_BOT_TOKEN}}" />
  <discord id="discordMessage" events="direct-message" bot-token="{{secrets.DISCORD_BOT_TOKEN}}" />
</triggers>

<steps>
  <step id="understand" name="Understand message">
    <script>
      return {
        provider: context.payload.provider,
        conversationId: context.payload.conversationId,
        text: context.payload.text?.trim() ?? ""
      };
    </script>
  </step>
</steps>

The workflow can branch on provider only when transport-specific behavior is required. Keep the main business logic independent of provider metadata where possible.

Normalized message fields

Common fields include provider, event, text, senderId, optional senderName, conversationId, conversationType, messageId, optional reply or thread identity, occurredAt, and bounded providerData.

Raw callback bodies, authentication signatures, tokens, headers, and full profiles remain outside context. This reduces accidental persistence and keeps provider implementation details from becoming the workflow API.

Prevent message loops

WOML ignores bot-authored or self-authored messages where the provider contract supports that detection. Your workflow should still avoid replying to every ambient channel message unless that is intentional. Prefer mentions, direct messages, and explicit channel allowlists.

Choose a provider for a first project

Telegram is generally the simplest end-to-end bot setup. Slack uses a bot token plus Socket Mode app token and workspace permissions. Discord uses a bot token, Gateway configuration, and numeric channel IDs. WhatsApp requires Meta Cloud API configuration, signed callbacks, and approved message templates for outbound initiation.

Provider-specific setup, secrets, permissions, and diagnostic commands are documented in the Communication section.