Slack connector

The Slack connector makes Slack the place where a workflow talks to people: it posts status and alerts, asks a named approver to sign off and waits for the answer, and lets a message, an emoji reaction, or a slash command start a flow. Slack is a surface for notifications and decisions, not a system of record, so the connector keeps run state in Neblex and writes the outcome back to the audit trail.

• Installs once per workspace, or org-wide on Enterprise Grid with a connection per workspace
• Messages are built with Block Kit, so an approval prompt, a summary table, or a form renders natively rather than as plain text
• An approval step pauses the run until an approver responds or a timeout fires, with the approver's identity captured
• One connector powers deterministic workflows, agent notifications, and human-in-the-loop steps, all in the same run log

The three jobs this connector is picked for most often, and what each one gets you.

• Put an approval in the flow.
• Route alerts with the context attached.
• Let people start a flow from Slack.

A real flow teams build on day one, with the actual step-level detail.

Discount over 20 percent waits for the deal desk before the quote is sent

A CPQ quote with a large discount pauses. Neblex direct-messages the deal desk lead with the numbers and buttons, and the run continues only on approval.

1. 1Upstream: a quote reaches pending approval with discount_pct, deal_name, amount, and rep_email.
2. 2Resolve approver: a data table maps the rep's region to a deal desk owner's email. Get user by that email returns the Slack user ID.
3. 3Request approval: post a Block Kit message to that user with deal_name, amount, discount_pct, a link to the quote, and Approve and Reject buttons. Pause the run.
4. 4Timeout: if there is no response in 4 working hours, escalate by posting to #deal-desk and re-assigning the decision.
5. 5On approve: set the quote to approved, update the original Slack message to show who approved and when, and let the send step run.
6. 6On reject: set the quote to rejected, capture the reason from a follow-up modal, and post it back to the rep in a thread.
7. 7Audit: the approver's user ID, the decision, and the timestamp are written to the run, so the approval is provable later.

Common patterns other teams start from with this connector.

• Deal won alerts. A closed-won opportunity posts to the revenue channel with the amount, product, and a link, and threads the onboarding checklist underneath. (Sales)
• Failed payment triage. A failed subscription payment opens a task, posts to the billing channel with the customer and amount, and tracks the dunning steps in the thread. (Finance)
• Query result digest. A scheduled Snowflake query posts a formatted summary each morning with a link to the run and the SQL that produced it. (Data)
• Escalation bridge. A high-priority ticket spins up an incident channel, invites the on-call and the account team, and posts the ticket context and CRM account detail. (Support)

Slack is a messaging surface, so the objects are conversational. State that must persist belongs in Neblex or the system of record, not in a Slack message.

What you can work with

Channel, Direct message, Message, Thread, User, User group, File, Reaction, Reminder, Scheduled message, Canvas, Bookmark

Interactive elements, approve and reject buttons, select menus, and modal forms, are built with Block Kit and their responses come back to the flow as structured values.

The connection holds only the OAuth scopes you grant the Neblex app in your workspace.

• OAuth 2.0 scopes. Bot and user tokens are scoped per capability, for example chat:write, reactions:read, users:read.email. Grant only what a flow needs.
• Channel-limited install. The app can be added to specific channels only, so it cannot post to or read channels it was not invited to.
• Signed requests. Every inbound event, command, and interaction is verified against Slack's signing secret and timestamp before a flow runs.
• Approvals in the audit trail. Each approval records the approver's user ID, the decision, and the time in the Neblex run, alongside every message the flow sent.

The shape of the vendor's limits, as published at the time of writing. Verify the exact figures for your plan; they change without notice. Neblex honors the vendor's own rate-limit and retry signals and backs off within them.

• Web API methods are rate tiered, with most read methods around 50 or more calls per minute, and message posting paced at roughly one message per second per channel
• The Events API delivers up to about 30,000 events per hour per workspace, retried three times with backoff on failure
• A message carries up to 50 Block Kit blocks, and a modal up to 100
• Interactive actions must be acknowledged within 3 seconds, which the connector handles before running the rest of the step
• File uploads are capped at 1 GB, and message text at 40,000 characters, with 3,000 the practical limit for readability