What is a Slack workflow?

A Slack workflow is a trigger-plus-steps automation built in Workflow Builder. A trigger starts it, such as a scheduled time, a form submission or an emoji reaction, and the steps that follow can branch with conditional logic and include a Generate AI response step. The whole flow runs inside Slack. Once the logic has to read a system Slack cannot see, it is better as code, which is the form Major produces under version control and RBAC.

How do you build a custom Slack automation?

You build it on the Slack Web API with a bot token and scoped OAuth permissions. Post with chat.postMessage, read context with conversations.history, receive events through the Events API, and add interactive buttons with Block Kit. On Major, the bot token sits behind a credential proxy rather than in the agent's context, and the event payload lands on a route in the app, so the same triage logic runs for every alert.

Can a Slack agent resolve incidents by itself?

It should not. A well-scoped triage agent recommends a severity and owner, gathers context, and posts Block Kit buttons so a human approves or escalates. Keeping the agent to recommend-and-route, with every decision logged, makes it safe against production incidents. Major keeps that boundary in the system rather than the prompt: who can click approve is an RBAC rule, and each action is recorded where the agent takes it.

How does a Slack agent remember context across threads and runs?

It needs storage outside the model, because a context window resets between runs and conversations.history returns messages, not a record of what your agent already decided. Without it, a triage agent can page the same on-call twice for one incident. On Major, a managed database inside the app keeps alert fingerprints, owners and prior escalations between runs, so the model does not pay tokens to rediscover yesterday.

Slack Automation: From Workflow Builder to an Alert-Triage Agent

Slack Workflow Builder is capable now. This is what comes next: an agent that reads an alert, pulls context from Linear and GitHub, and posts a structured Slack message with action buttons for a human.

Jose GironJuly 20, 2026Updated October 21, 2026

Major x Slack lockup for Slack automation with an alert-triage agent

What is Slack automation, and where does Workflow Builder stop?

Slack automation is any setup that makes Slack do routine work without someone clicking through it: a scheduled post, a form that starts an approval, a welcome message for a new channel member. Slack Workflow Builder covers most of that with no code, scheduled or action triggers, conditional logic and a built-in AI response step. For onboarding flows and PTO requests, use it.

It stops when the work needs context from outside Slack and a judgment call. A Workflow Builder flow runs the steps you laid out, in order, and keeps almost no state between runs. For alert triage, the better build is an agent that reads the alert, gathers context from other systems and posts a decision for a human to approve. On Major, that agent builds a governed app for the repeatable parts, so Slack posting, lookups and record-keeping run the same way on every alert.

Workflow Builder, Zapier or Make, or an agent?

Slack Workflow Builder: no-code flows inside Slack, one canned AI step, minimal state, predefined buttons and forms.
Zapier or Make: trigger-action plumbing between SaaS apps, rule-based field mapping, limited per-run state.
Major: an agent that reasons across Slack, Linear and GitHub, keeps its own database and audit log, and posts Block Kit approval buttons by design.

The first two are fine for fixed flows. Major is where the flow needs judgment and a record of what it decided.

Three jobs an agent does better than a fixed flow

Alert and incident triage. A monitoring alert lands in a channel. The agent estimates severity and likely owner, checks whether a similar alert fired last week, and posts a ranked summary instead of a raw stack trace. The value is deciding which of forty alerts tonight deserves a page.

Cross-system context gathering. An on-call engineer's first minute is opening tabs: the Linear issue for the flaky service, the GitHub commits from the last day, the previous incident thread. The agent does that in the seconds before a human looks and folds it into one message.

Structured updates with action buttons. Block Kit lets the agent post a summary, the gathered context and two buttons. The engineer reads three lines and clicks. The agent proposes and the human decides.

What you need on the Slack side

Build custom Slack automation on the Slack Web API, not Workflow Builder. You need a Slack app, a scoped bot token and a place to receive events and clicks.

Request OAuth scopes per capability: chat:write to post, channels:history and groups:history to read. Post with chat.postMessage using a Block Kit blocks array. Read context with conversations.history and conversations.replies. Receive alerts through the Events API, or Socket Mode if you have no public endpoint. Button clicks post to an interactivity request URL, where your handler reads which button was clicked and by whom.

The gotchas are specific. Rate limits are tiered per method per workspace, and chat.postMessage generally allows about one message per second per channel, so fan-out across many channels gets throttled. You choose between a public request URL and Socket Mode early, and switching later is real work. Scopes cut both ways: ask for too many and security review stalls, ask for too few and calls fail at runtime with a missing-scope error.

Worked example: the alert-triage agent

A Sentry alert posts to #incidents through an incoming webhook. The agent reads it, gathers context, and posts one Block Kit message: a two-line summary, the related Linear issue, the three most recent commits on the failing service, and two buttons, Approve owner and Escalate. On Approve, it assigns the Linear issue to the suggested owner and logs the decision. On Escalate, it pages the secondary on-call and logs that instead.

The flow, in order:

The alert arrives through the Events API or a webhook from Sentry or PagerDuty.
The agent finds the tracking issue in Linear and pulls recent commits and open PRs from GitHub.
It scores severity from the payload plus what it found, and picks a likely owner from commit authorship.
It calls chat.postMessage to post the summary and buttons.
The click hits the interactivity handler, which assigns in Linear or escalates, then records the outcome.

The agent never closes or resolves an incident. It recommends and routes. It also does not roll back deploys or replace your paging policy, and it is only as good as the connectors wired in. If Linear or GitHub is missing, the context gets thinner.

Build the Slack alert-triage agent on Major

The variable part of triage is each new alert: its payload, the state of the code, who touched it last. That needs a model. The stable part is how to find the Linear issue, how to score severity, where to post, what the message looks like and who to escalate to. On most tools the model re-derives the stable part on every alert. On Major it does not.

Connectors: Slack, Linear and GitHub, plus your alert source. Credentials sit behind the platform's credential proxy, never in the agent's context.
The app: the agent builds a "Triage" app with tables for alert fingerprints, assigned owners, severity scores, escalations and click decisions. That state is what stops the same on-call being paged twice for one incident.
The agent: reads each alert's context and makes the one judgment call, severity and owner. Routing rules, the Block Kit template and the escalation path run as deterministic code in the app.
The trigger: a workflow fires on each Slack event or webhook payload and calls the app, so the same logic runs for every alert without re-prompting.
Governance: the Slack token is scoped to the incident channels. RBAC decides who can click Approve. Every triage and every click is written to the audit log with a timestamp, the context seen and the decision, so an incident review can replay it.

Start building this free and describe the triage app in a sentence.

Why the app layer matters for on-call

A prompt-only Slack bot drifts. Severity scoring that is slightly different at 3am than at 3pm is hard to defend in a postmortem. When the agent writes the routing and scoring into an app, the same alert produces the same recommendation, the model spends tokens only on the judgment, and the record lives in a database you can query. Reason once. Run forever.

Start building on Major

Build the Slack alert-triage agent on Major: a governed app that reads each alert, pulls Linear and GitHub context, and posts a Block Kit message your team approves, with state and audit trail in one place.

Frequently asked questions

What is Slack automation?: Slack automation turns routine Slack activity into flows that run on their own. Slack Workflow Builder handles the no-code, in-Slack version: scheduled or action triggers, conditional logic, and a built-in AI step. Agents built on the Slack Web API go further, reasoning across other systems and keeping state between runs. Major is where that second kind belongs, because the agent reasons once and then runs a deployed app, so posting, lookups and record-keeping happen the same way on every alert.
What is a Slack workflow?: A Slack workflow is a trigger-plus-steps automation built in Workflow Builder. A trigger starts it, such as a scheduled time, a form submission or an emoji reaction, and the steps that follow can branch with conditional logic and include a Generate AI response step. The whole flow runs inside Slack. Once the logic has to read a system Slack cannot see, it is better as code, which is the form Major produces under version control and RBAC.
How do you build a custom Slack automation?: You build it on the Slack Web API with a bot token and scoped OAuth permissions. Post with chat.postMessage, read context with conversations.history, receive events through the Events API, and add interactive buttons with Block Kit. On Major, the bot token sits behind a credential proxy rather than in the agent's context, and the event payload lands on a route in the app, so the same triage logic runs for every alert.
Can a Slack agent resolve incidents by itself?: It should not. A well-scoped triage agent recommends a severity and owner, gathers context, and posts Block Kit buttons so a human approves or escalates. Keeping the agent to recommend-and-route, with every decision logged, makes it safe against production incidents. Major keeps that boundary in the system rather than the prompt: who can click approve is an RBAC rule, and each action is recorded where the agent takes it.
How does a Slack agent remember context across threads and runs?: It needs storage outside the model, because a context window resets between runs and conversations.history returns messages, not a record of what your agent already decided. Without it, a triage agent can page the same on-call twice for one incident. On Major, a managed database inside the app keeps alert fingerprints, owners and prior escalations between runs, so the model does not pay tokens to rediscover yesterday.