Slack workflow posts
A slack_post action selects an existing Slack channel binding and accepts text of 1–3000 characters. It requires org:manage_integrations, including the workflow author's saved API-key ceiling. Project write permission alone does not grant outbound posting. The binding and its active installation must belong to the workflow tenant.
Supported merge fields are the existing workflow fields: firstName, lastName, fullName, email, dealTitle, orgName. Use {{firstName|friend}} for a fallback. Unsupported or malformed expressions are rejected. Contact and deal-primary-contact values come from current tenant-scoped records; absent values use the fallback. Rendered text must also fit the length limit.
The event transaction queues exactly one durable outbox row per run step. A repeated queue returns the original outbox ID. Rolling back the event rolls back the post. Dry runs validate and report would_queue without creating an outbox row. A queued step is not proof that Slack received a message.
The minute drain checks the workflow and installation again, opens the installation's sealed bot token and sends to the binding's exact Slack channel. The token is never stored in the target, payload, step result or diagnostics. A successful Slack response with a ts records delivered, providerRef, and deliveredAt. Auth/channel rejection records failed. A 429 backs off according to Retry-After (at least the local exponential backoff); only a transport-certified pre-send failure or 5xx response known to precede any outbound body bytes may otherwise retry. Generic 5xx responses remain unknown. Attempts are bounded.
A timeout, network exception, malformed response, missing success timestamp or ambiguous provider error records unknown. This status is terminal and never automatically replayed. The worker persists unknown before calling the transport; death after a send therefore cannot cause a lease-expiry replay. This favors avoiding duplicate external effects over guaranteeing eventual delivery. Review unknown outcomes in Slack before deciding on a new, separately authorized workflow step; never reset a receipt to queued.
Module-local delivery is supplied by goodqa#6278. Production action registration, migration numbering, catalog and cron wiring are handed to goodqa#6261 through docs/ops/workflow-slack-post-node-20261023/REGISTRATION-PROPOSAL.md. Until adoption, this module does not expose a production workflow action.
Provider references: chat.postMessage, rate limits.