This document sets expectations about what the Slack integration does not do, either by design, because of Slack platform behavior, or because it falls outside the current scope. The Slack integration sends alert messages from iPaaS.com to a designated member in your Slack workspace; the limitations below describe how that delivery behaves at the edges so you can plan around them.

This integration works with the Slack Web API (base URL https://slack.com/api). Slack maintains a single, continuously updated Web API rather than dated version numbers, so there is no fixed remote version to pin. It is built for one-way alert delivery to Slack; it is not built to read Slack conversations, channels, or other Slack data back into iPaaS.com. The behaviors described here are current at the time this documentation was written; subscribers or their MiSP should validate any behavior that is sensitive to their own workspace configuration in a staging environment before relying on it in production.

Messages flow in one direction, from iPaaS.com to Slack, and are sent as new messages. The integration does not read messages back from Slack, and it does not update or delete a message after it has been delivered. This is the appropriate shape for alerting: each notification is a standalone post to the recipient. This is current at the time this documentation was written.

Alerts are sent only for unresolved errors. A message is delivered only when it carries an error marker (an ExternalSystemId) and its RetryCount has reached 3, indicating the error did not clear on earlier attempts. Messages that do not meet these conditions are intentionally not sent. This is by design at the time this documentation was written: if you expect a notification and do not receive one, confirm the source message meets these criteria rather than treating the absence as a failure.

The recipient is resolved by matching the profile name you supply against the Slack member's Name first and then their Real Name. The member must already exist in the connected workspace. Matching is sensitive to exact spelling and casing, so a name that does not match resolves to no recipient and the alert is not delivered. At the time this documentation was written, subscribers or their MiSP should validate that the configured name resolves to the intended member in a staging environment before relying on it in production.

Slack limits an individual message block to 3,000 characters and a single message to 4,000 characters total. When an alert body is longer than the supported limit, it is automatically shortened and split into blocks, and a follow-up notice is appended so the recipient knows the content was truncated. The full original content is not delivered to Slack. This behavior is current at the time this documentation was written.

At the time this documentation was written, bulk initialization is not supported. The integration does not backfill historical alerts; only messages that meet the delivery criteria after the integration is configured are sent.

At the time this documentation was written, the current release focuses on one-way alert delivery. It does not include collision handling, scheduled polling, propagation of deletions to Slack, or custom fields. These are intentional scope decisions for the current release; if your workflow needs a different shape, submit a feature request to your iPaaS.com partner channel describing the requirement so it can inform future enhancements.

The default mapping ships with a placeholder recipient that must be replaced before the integration is enabled.

This document describes six limitation areas of the Slack integration.