Communication Overview

WOML uses communication providers in four distinct ways.

Triggers normalize inbound data under context.payload. Notifications do not become workflow steps. Messaging services are managed effects. Custom providers transport bounded notification data while Rust retains approval authority and delivery identity.

Follow one provider through the system

A Telegram bot can start a run when it receives a message. The workflow reads provider-independent fields from context.payload, performs business or AI work, and replies through services.telegram.send().

The same provider can also appear inside <notify> for a human approval or lifecycle message. That notification is runtime behavior around a durable event rather than a business step result.

Choose the correct surface

Use a trigger when an inbound message creates a run. Use a messaging service when sending a message is ordinary business work. Use notification tags when the runtime must deliver approval controls or lifecycle information. Use a custom provider when a project needs another notification transport without waiting for WOML to add a built-in vendor.

Keeping these surfaces separate prevents notification delivery from pretending to be business output and prevents provider scripts from owning approval authority.

Normalize business logic

Communication triggers provide common fields such as provider, event, text, sender, conversation, message, thread, and occurrence time. Build the main workflow against those fields and isolate provider-specific behavior to the edges.

Raw signatures, headers, access tokens, provider envelopes, and full profiles do not enter context.