Slack and Microsoft Teams

BytesMap connects chat to saved workflows. A signed chat command identifies the sender, a linked BytesMap account supplies that person's permissions, and the worker executes a published workflow. A workflow's notification step can deliver results to a configured Slack, Teams, email, Discord, Telegram, or webhook destination.

Before connectingCopy Anchor Link

• Run the API at a public HTTPS address and set BYTESMAP_ADVERTISED_ORIGIN to that API origin. Slack and Teams must reach it. The dashboard origin is not the command endpoint.
• Run the BytesMap worker against the same metadata database and encryption key as the API. Keep it running to process queued commands.
• Publish a workflow. To return statistics to chat, add a Notification step and select a tested notification channel. Saving the connection does not execute or test that workflow.
• A workspace owner or administrator configures the integration. Each person links their own account and keeps their existing resource permissions.

Open Settings → Notifications. Notification channels configure outgoing delivery. Chat integrations configure authenticated incoming commands. An outgoing webhook alone does not authorize chat commands.

SlackCopy Anchor Link

1. Choose Connect an app → Slack in Chat integrations. Copy the command callback URL.
2. Create a Slack app for your Slack workspace. Under Slash Commands, create /bytesmap and use the copied URL as its Request URL.
3. Install the app in the workspace. Copy Basic Information → App Credentials → Signing Secret into BytesMap.
4. Enter the Slack workspace ID and the channel IDs allowed to invoke commands, one per line. A channel's details show its ID. Names such as #operations are not IDs.
5. Add short command names mapped to published workflows, then save the connection.

BytesMap verifies Slack's signature over the original request body, including its timestamp, and checks the stored workspace and channel IDs. Slash-command responses are ephemeral. No Slack bot token or response URL is stored by the command handler.

Microsoft TeamsCopy Anchor Link

1. Choose Microsoft Teams in Chat integrations and copy the command callback URL.
2. Follow Microsoft's outgoing webhook setup to create an outgoing webhook named BytesMap in your team.
3. Use the copied URL as its callback URL. Copy the generated base64 security token into BytesMap's Teams security token field.
4. Enter the Microsoft tenant ID and allowed channel IDs. A channel ID is available in its copied Teams link; decode the channel segment if necessary.
5. Map published workflows to command names and save.

This integration uses Teams outgoing webhooks with HMAC verification. Invoke it with @BytesMap in an allowed standard team channel. It does not support private channels, direct messages, or interactive bot cards. Teams replies are visible in the channel. This is not an Azure Bot or a marketplace app installation.

Link your accountCopy Anchor Link

1. In BytesMap, choose Link my account for the connection.
2. Copy the generated command and send it in an allowed channel. Codes expire after ten minutes.
3. Return to BytesMap and choose Check identity. Compare the proposed chat user ID with your own Slack or Teams identity before choosing Confirm my account.

Using a code in chat does not grant access until the signed-in BytesMap user confirms that specific identity. A code cannot be reassigned to another chat identity after its first use; cancel it and generate a new code if the wrong person used it. Confirm only your own ID, especially in Teams where channel messages are shared.

Workspace membership is part of the link. Removing a member deletes their binding. Inviting the same person again does not restore that binding.

CommandsCopy Anchor Link

Use /bytesmap in Slack or mention @BytesMap in Teams before each command.

Commands cannot submit arbitrary SQL, shell commands, or unpublished definitions. The integration records the selected published revision. Publishing a new revision does not silently change an approved command: update the connection to select the new revision before running it. Pausing remains available even when a selected workflow has changed.

Delivery and failuresCopy Anchor Link

The HTTP callback acknowledges queueing; it does not wait for the workflow to finish. Use status for completion. Workflow notification steps deliver the actual results to their explicitly configured channels, which may differ from the channel where the command was issued.

Verified provider retries use the same durable request identity and do not start another execution. Multiple workers claim jobs transactionally. Runs use the linked person's current permissions and the existing workflow engine, including its per-step access checks and effect handling.

Pausing an integration, unlinking an account, or removing membership prevents queued commands from starting. Already-started external effects cannot be undone. Integration edits invalidate jobs queued against the previous configuration. Jobs older than ten minutes fail before execution; each started workflow has a 60-second execution deadline. Interrupted or uncertain executions are not automatically retried. Check the destination and workflow history before starting a replacement.

Queueing is bounded to 100 pending commands per workspace, 100 new commands per workspace per minute, and 10 per linked account per minute. Provider retries of an already-queued request do not consume another slot. The API's request limiter applies as well. Request bodies are limited to 16 KB and JSON inputs to 4 KB.

Signing secrets and queued input values are encrypted. Input values are cleared when a run finishes. Command receipts are retained for seven days; workflow history and workspace audit retention are separate. The generic audit record does not include chat message bodies, credentials, or input values. Workflow execution history follows the same retention and access controls as runs started inside BytesMap.

Verify your installationCopy Anchor Link

Use a dedicated channel and a harmless published workflow first. Confirm its input description, run once, inspect the workflow history, and verify delivery to the chosen notification channel. Then pause the integration and confirm it no longer accepts commands. Local protocol and browser tests validate BytesMap's implementation; your provider installation, HTTPS reachability, worker availability, and real delivery must also be checked in your own environment.