Agentforce in Slack: why the only agent that runs there is an Employee Agent, and what that decides

Salesforce has spent the last year turning Slack into the front door for internal AI work, and at TrailblazerDX 2026 it made the intent explicit — Slackbot as an MCP client, native CRM inside Slack, a Slack Agent Kit for multi-platform deployment, Block Kit for structured AI responses. The pitch is that your workforce already lives in Slack, so that’s where the agents should meet them.

That’s a good pitch. But under the marketing there’s one architectural fact that determines almost everything about how you build for it, and it’s easy to miss: you can only deploy one type of Agentforce agent in Slack — an Employee Agent — and it runs as the person who invoked it. Not as a service account. Not as a shared bot identity. As Dana in Finance, with Dana’s Salesforce permissions and Dana’s sharing rules. Once you internalize that, the rest of the design — grounding, governance, licensing — follows from it. Get it wrong and you either build an agent that can’t see anything useful or one that leaks records across your org. This post is how the integration actually works, and where the running-as-the-user model helps you and where it bites.

Employee Agents only — and why the constraint is the feature

Agentforce has a customer-facing side (service agents that talk to your customers) and an internal side (Employee Agents that help your own people). In Slack, only Employee Agents are supported. You cannot expose a customer-facing service agent in a Slack workspace.

The defining behavior of an Employee Agent is that it identifies the invoking user at runtime and acts on that user’s behalf, following that user’s own Salesforce permissions and sharing model. This is the whole ballgame. When someone in Slack asks the agent “what’s the status of the Acme renewal?”, the agent resolves records as that user — so it can only surface what that user is already allowed to see in Salesforce.

The Slack agent inherits the asker’s permission set and sharing rules. That’s not a limitation to work around — it’s your security boundary, handed to you for free. It’s also a boundary you’re now on the hook to have configured correctly.

For enterprise deployment this is the right default. You don’t build a separate authorization model for the agent; you reuse the one your org already enforces. But it also means your Salesforce sharing model is now doing double duty as your Slack agent’s access control — which is a reason to get permission sprawl under control before you put an agent in front of it, not after.

How an agent actually gets into Slack

The setup is a sequence across two products, and the order matters. At a high level:

1. Build and activate the agent in Salesforce. You author the Employee Agent in Agent Builder — Topics, Actions, instructions — the same way you’d build any agent. If you want a running start, Agent Builder ships Slack-specific templates (below).
2. Add a Slack connection to the agent in Agent Builder. This is the step that makes the agent Slack-aware.
3. Install the agent into the relevant workspaces. A Salesforce admin coordinates with a Slack admin to connect the org to Slack and complete the setup steps on both sides.

Access is governed from Salesforce, not Slack. Member access for Employee Agents is assigned automatically based on Salesforce permissions — specifically, users get access to the agent through permission set assignment in the org. So “who can use this agent in Slack” is answered in Setup, by assigning (or not assigning) the permission set, exactly like any other Salesforce capability. If someone can’t see the agent in Slack, you check their permission sets, not their Slack roles.

The templates — a real head start

You don’t have to design an internal agent from scratch. Agent Builder ships three Slack templates, pre-loaded with Topics, Actions, and workflows, so you can stand one up and then tailor it:

• Employee Help Agent — resolves internal issues by answering FAQs from your internal resources and Slack conversations. This is the classic HR/IT deflection use case: “how many PTO days do I have left,” “how do I request a new laptop.”
• Onboarding Agent — helps onboard new hires by creating onboarding canvases and answering FAQs from custom knowledge bases. New-joiner questions are high-volume, repetitive, and perfect for an agent.
• Customer Insights Agent — uses Salesforce data to summarize customer information, find subject-matter experts in Slack, and generate customer briefs. This is the one that pulls CRM into the flow of a rep’s day.

Start from the template closest to your use case, then swap in your knowledge sources and Actions. It’s far faster than a blank agent, and the Topics are already scoped sensibly.

Grounding: Slack’s real-time search changes what “context” means

An internal agent is only as good as what it can read, and this is where the Slack integration adds something the standalone platform doesn’t. Beyond grounding on your Salesforce data and knowledge, an Agentforce agent in Slack can search across connected third-party apps in real time — Google Drive, Microsoft OneDrive, Asana, Box, PagerDuty, Highspot, and more — alongside Slack messages and files.

That matters because the answer to an employee’s question frequently doesn’t live in Salesforce. The policy doc is in Google Drive; the runbook is in a Slack channel; the project status is in Asana. Real-time search lets the agent draw on where the knowledge actually is, so it can produce grounded answers instead of confidently wrong ones. And for repositories that aren’t covered by an off-the-shelf connector, Slack’s custom search connector API extends the same real-time search to any data source your org runs.

The grounding discipline still applies — an agent that retrieves the wrong document answers wrong, exactly the failure mode we covered for Intelligent Context. Slack widens the sources; it doesn’t remove your obligation to curate them and check that the agent retrieves the right one.

The 2026 developer surface: MCP, Block Kit, the Agent Kit

If you’re building beyond the templates, three things from the TDX 2026 wave are worth knowing:

• Block Kit for AI responses. Agent replies in Slack don’t have to be a wall of text. Block Kit — including prebuilt Block Kit Tables — lets an agent return structured, interactive responses (a formatted table of open cases, a set of action buttons) instead of a paragraph. For anything data-shaped, use it; a table reads better than prose.
• Slackbot as an MCP client. Slack is leaning into the Model Context Protocol as the standard way agents reach tools and data. If you’ve invested in MCP servers for your systems, Slack becoming an MCP client means those tools are reachable from the same surface your employees already use.
• The Slack Agent Kit. A path to deploying agents across surfaces rather than hand-wiring each one. If your roadmap includes agents in more than one place, it’s the piece that keeps you from rebuilding the integration per channel.

None of these are required to ship a useful Employee Agent from a template. They’re what you reach for when the template’s plain-text, single-system answers stop being enough.

What it costs

Employee Agents deploy across Lightning Experience, the Salesforce mobile app, Enhanced Web Chat, and Slack — and they consume against the same Agentforce pricing as any other agent. The models you’ll encounter:

• Flex Credits — the consumption model Salesforce steers most deployments toward. Credits are purchased at $500 per 100,000, and a standard agent action runs 20 credits ($0.10). Flex Credits cover every use case, including employee-facing agents.
• Conversation-based — a flat $2 per conversation, where a conversation is any continuous agent interaction inside a 24-hour window, regardless of how many messages it contains.
• Per-user — a flat “digital labor” license from $125 per user per month, if you’d rather not meter usage at all.

Two constraints worth planning around. First, Flex Credits and conversation pricing can’t coexist in the same org — you pick one consumption model per org, and it applies to all your agents, customer- and employee-facing alike. Second, and useful: Enterprise Edition and above get 100,000 Flex Credits free through Salesforce Foundations, which is enough to pilot an internal agent without a new purchase order.

For employee-facing work specifically, the usage profile tends to be lower volume but higher per-interaction complexity than customer service — fewer conversations, but each one doing real multi-step work. That shape usually favors Flex Credits over the flat conversation fee, but the honest answer is to instrument a pilot and measure actions-per-conversation before you commit. The free Foundations credits exist precisely so you can.

The governance you can’t skip

Because the agent runs as the invoking user, two things become your job and no one else’s:

1. The sharing model is the access control. If a user can see a record in Salesforce, the Slack agent can surface it to them. If your org over-shares — broad role hierarchies, permissive sharing rules, a permission set that grants more than it should — the agent will faithfully expose exactly that. An internal agent is a good forcing function to finally run the security review you’ve been deferring.
2. An agent in Slack is still a member of your agent fleet. It needs an owner, a defined scope, monitoring, and a retirement plan like any other — the fleet governance discipline doesn’t get a pass just because the surface is Slack. “It’s just a helper bot in a channel” is how ungoverned agents accumulate.

The takeaway

Agentforce in Slack is one of the cleaner internal-AI deployments Salesforce offers, and most of that cleanliness comes from a single constraint: only Employee Agents run there, and they run as the person who asked. That gives you templates that work out of the box, access control you already maintain, and real-time grounding across the tools your team actually uses — Drive, OneDrive, Asana, Slack itself. The catch is the mirror image of the benefit: your Salesforce sharing model is now your Slack agent’s security boundary, so the agent is only as trustworthy as the permissions underneath it. Build from a template, ground it on curated sources, meter a pilot on the free Foundations credits, and fix your sharing model first — and you get a genuinely useful teammate in the place your people already work, without standing up a parallel authorization system to run it.

If you’re not sure whether your data and permissions are ready to put an agent in front of, that’s exactly what the Agentforce Readiness Assessment is for.