Automating Slack with Agentforce: the actions an agent takes, the workflows that call it

Most writing about Agentforce in Slack stops at the demo. Someone @mentions an agent, asks it to summarise a renewal, and gets an answer in the thread. That half is real, and we’ve covered why the agent that runs there is an Employee Agent running as the person who invoked it. It’s also the least interesting one.

The automation lives in the other direction. An agent that posts a canvas to a channel when a case closes. A Slack workflow that fires an agent off an emoji reaction, a form submission, or a Salesforce record change, with no one typing anything. There, Slack stops being a chat window for your agent and starts being a surface it works on.

The build has two halves that most teams conflate: what the agent can do in Slack, which you configure in Agent Builder, and what can trigger work, which you configure in Slack’s Workflow Builder. Get the halves straight and the rest is plumbing. This post is both halves, the Flow that joins them, and the licence and permission traps that sit in the seams.

The agent reaching into Slack: Slack Actions in Agent Builder

The first half is the agent taking action in Slack rather than only answering. In Agentforce Agent Builder you can give an agent a set of prebuilt Slack Actions, and they are the verbs that turn a conversational agent into a working one:

Create Canvas, to write a structured summary as a Slack canvas instead of a wall of message text.
Message Channel and Send DM, to post where the work is happening or to the person who needs it.
Create Channel, to spin up a space for an incident, a deal, or a case.
Search Slack and manage Lists, to read and update the record of work that already lives in Slack.

You add these through a General Slack Actions capability on the agent, and when the prebuilt set runs out, you write custom Slack actions that call the Slack Web API through a Salesforce authentication provider. A custom action is how you get from “message a channel” to “post this specific block layout to the channel named after the account, then pin it.”

One licence trap to note up front: some of these actions are gated. Create Canvas, for one, is not available on free Slack, and the richer Slackbot actions ride the paid AI plans. Confirm the action you are designing around is available on the plan your users are on before you build a workflow that depends on it.

The trigger side: Slack Workflow Builder

The second half is what starts the work. Slack’s Workflow Builder is the no-code automation tool, and in 2026 it triggers on a useful range of events. The supported trigger types include a link someone clicks, a schedule, an emoji reaction added to a message, a new member joining a channel, a submitted form, an inbound webhook, and connector events from outside systems.

That last one matters for CRM work. Slack ships a Salesforce connector whose triggers fire when a record is created or updated, so a closed-won opportunity or a status change on a case can start a Slack workflow without any middleware.

Workflow Builder also gained AI natively. The Generate AI response step takes a plain-language prompt and can summarise, translate, draft, or classify, grounded in Slack knowledge like channels, canvases, and files. You add it to a workflow, write the prompt, and choose what it reads.

A precision point, because the marketing blurs it: as of now there is no confirmed, separately named “Agentforce step” you drop into Workflow Builder. What you actually compose with is the generic AI response step, the Salesforce connector’s triggers and actions, and your own Employee Agent invoked in Slack. Build against what exists, not against a step you saw in a slide.

The Flow in the middle

The two halves meet in Salesforce Flow. Slack Workflow Builder is strong at Slack-side triggers and simple steps; Flow is where branching logic and record work belong. Salesforce’s own guidance is to build two-way no-code automations by pairing Flow with Workflow Builder, each doing the side it is good at.

A concrete shape, drawn from the pieces above rather than any one product screen, looks like this:

Trigger  (Slack Workflow Builder): :handoff: emoji added to a message
  → Step (Salesforce connector): create a Case from the message
  → Step (invoke agent, Employee Agent): draft a first response,
           grounded in the account's Data 360 context
  → Action (Slack): post the draft as a Canvas in the channel,
           for a human to review and send

Notice where the agent sits: it drafts and assembles, then hands a canvas to a person. The trigger and the record creation are deterministic Slack and Flow steps. The judgment step is the agent. The send stays human. That division is the same one that makes any Agentforce build safe: let the agent do the reversible, assembling work, and keep the irreversible action behind a person or a guardrail.

The permission model you inherit

Two governance facts shape every Slack automation, and both come from how Agentforce runs in Slack rather than from Workflow Builder.

An agent in Slack acts within the invoking user’s permission model, respecting field-level security and sharing, and its exchange passes through the Einstein Trust Layer, which masks sensitive data and enforces the model’s data-handling policy. So an agent that posts a canvas to a channel of forty people can assemble that canvas only from records the person who triggered it can see. The same running-as-the-user model that makes this safe in a DM becomes a leak risk the moment output lands in a wide channel, which is the exact hazard the Slackforce Surfaces governance question turns on.

The second fact is licensing. Using Agentforce in Slack needs a paid Agentforce licence, and a Slack user who has no Salesforce account needs a provisional Salesforce licence to interact with the agent at all. Skip that and your workflow works for the three people who happen to have full Salesforce seats and silently fails for everyone else.

What it takes to stand one up

The setup is admin work on both platforms, and the order is worth having in front of you.

Connect the Salesforce and Slack orgs and enable the Slack integrations, which a Salesforce admin and a Slack workspace or Enterprise Grid admin do together.
Enable Einstein and the Agentforce features, and map Slack identities to Salesforce users so the running-as-the-user model has someone to run as.
Build the agent in Agent Builder as an Employee Agent, and attach the Slack Actions it needs. The Slack-native agent type is the Employee Agent; other agent types are aimed at customer channels.
Build the trigger and the simple steps in Workflow Builder, and move branching or record logic into Flow.
Check plan gating for any Slackbot or canvas action before you depend on it.

For a request that has to span several systems, one Slack prompt can fan out to more than one agent through multi-agent orchestration and the A2A protocol, with a routing agent delegating to specialists and returning one answer. That is the ceiling of what this gets you: not a smarter chatbot, but Slack as a place where triggered, governed work runs.

Where the line sits

The reason to build this is that the work already happens in Slack, so the automation should too. An emoji that opens a case, an agent that drafts the reply, a canvas that lands in the channel for a human to send: each step is small, and together they remove the copy-paste between Slack and the CRM that eats a support team’s afternoon.

The line to hold is the same one every Agentforce build has. The agent triggers, reads, drafts, and assembles inside one person’s permissions. The actions that move money, close a customer’s case for real, or post to an audience the triggering user couldn’t see themselves stay behind a human or a hard guardrail. Build the automation so the agent does the tedious 80 percent and a person still owns the 20 that would be expensive to get wrong.

Understanding the basics

Can I trigger an Agentforce agent from a Slack workflow?

You compose it rather than pick a single “run agent” step. Slack Workflow Builder fires on triggers like an emoji reaction, a form submission, a schedule, or a Salesforce record change through the Salesforce connector, and from there you use Workflow Builder’s AI response step, the connector’s record actions, and your Employee Agent to do the work. Salesforce Flow handles the branching and record logic in between. There is no separately named “Agentforce step” in Workflow Builder today, so build with the pieces that exist.

What can an Agentforce agent actually do inside Slack?

Through Slack Actions configured in Agent Builder, an agent can create a canvas, message a channel, send a DM, create a channel, search Slack, and manage lists, and you can extend it with custom actions that call the Slack Web API. Some actions are plan-gated, and Create Canvas is not available on free Slack, so confirm availability on your users’ plan before designing around an action.

Do users need a Salesforce licence to use an agent in Slack?

Yes. Agentforce in Slack requires a paid Agentforce licence, and a Slack user without a Salesforce account needs a provisional Salesforce licence to interact with the agent. The agent then runs as that user, with their permissions and sharing, so licensing and the permission model are tied together.

What is the difference between this and Slackforce Surfaces?

Slackforce Surfaces is about a person describing a dashboard or deck in a prompt and Slackbot building it live. This is about automation: agents taking Slack actions on their own and Slack workflows triggering agent work off events. They share the same permission hazard, because output built under one person’s access can land in a channel of many, which is the governance question to design around in both.

Want to wire Agentforce into the Slack workflows your team already lives in, without leaking a record into a channel that shouldn’t see it? Talk to us. Scoping the agent’s actions, the triggers, and the permission model so the automation is safe is the build we do against real orgs.