All insights

Agentforce

Slackforce Surfaces: the dashboard a Slack prompt builds, and the permissions it inherits

Slackforce Surfaces lets anyone describe a dashboard, report, or deck in Slack and have Slackbot build it live from Salesforce data. The build is easy. The governance question is what happens when a surface built under one person's permissions gets posted in a channel of forty. Here is how it works and where to be careful.

Slackforce Surfaces: the dashboard a Slack prompt builds, and the permissions it inherits, article illustration

Someone in your #revenue channel will type “build me a pipeline dashboard” and get one back in the thread, in a minute. That is Slackforce Surfaces, one of the three interfaces Salesforce is leading with under AIforce, and it shipped at Dreamforce 2026.

Slackbot takes a plain-language prompt and builds a dashboard, report, executive deck, poll, or interactive microsite, grounded in real-time data from your Slack conversations and connected apps such as Salesforce and Google Drive. Nobody leaves the conversation. Nobody opens a report builder.

My read: the build is the easy part, and the demo will land every time. The question worth your attention is the one the demo skips.

A surface gets built under the permissions of the person who asked for it, then lands in a channel where other people can see it. Those are two different permission scopes, and the gap between them is where a number reaches someone who was never supposed to see it.

What a Surface is, and what it replaces

A Slackforce Surface is a generated, interactive view your team can filter, explore, comment on, and act on together, built from a prompt. Salesforce’s examples are the obvious ones: a pipeline view, a forecast, a case backlog, a campaign report, pulled from Sales Cloud, Service Cloud, Data 360, or Tableau and rendered right in the thread.

What it replaces is the ad hoc reporting queue. Today an exec asks an analyst for “open pipeline by stage, but only the West team, and can you add last quarter as a comparison.” The analyst builds it, shares a link, and fields three follow-up tweaks.

Slackforce Surfaces collapses that loop into a conversation with Slackbot. For the throwaway, answer-a-question-now report, that is a gain worth having, and it takes work off the people who currently spend their afternoons building other people’s dashboards.

A Surface is a different tool from the Slack agent I wrote about earlier. The Employee Agent in Slack answers a question in a chat turn. A Surface produces a visual artifact that persists in the channel and updates. One is a conversation. The other is a small BI deliverable you conjured with a sentence.

Availability, and the snapshot gap until October

You can use it now, on more plans than you might expect. Slackforce Surfaces is available today for workspaces with Slackbot enabled, including Enterprise+, Business+, Pro, Legacy, and Free tiers. The low bar to entry is the point Salesforce is making, and it is also why this will spread through your workspace faster than a governed rollout would.

One detail changes how much you should trust an early Surface. Live-data support, where a dashboard refreshes as the underlying data changes, is due in October 2026. Until that lands, a Surface is a snapshot taken at the moment it was built.

A pipeline dashboard someone generated on Monday and pinned to a channel is Monday’s pipeline, not today’s, and nothing on the card tells a casual reader that. Treat pre-October Surfaces as point-in-time, and say so when you share one.

The permission model is the whole build

The mechanism that makes Surfaces safe to offer is the same one that makes the Slack agent safe. Slackbot uses the Salesforce data you already have permission to access, subject to the permissions already granted to Slack’s AI tools. A rep who cannot see other reps’ opportunities in Salesforce cannot build a Surface that shows them. The running user’s access is the ceiling.

The mechanism mirrors the model I described in the Data 360 governance post: an action inherits the identity of the person it runs for, and your Salesforce sharing rules and field-level security do the enforcing. If your permission model is right, the Surface is bounded by it.

The Surface inherits the builder’s permissions, not the channel’s. Getting that right at the org level is the difference between a helpful tool and a fast way to broadcast numbers.

The uncomfortable corollary: the enforcement is only as good as your sharing model. A finance lead with org-wide read on Opportunity can build a Surface showing every deal in the company, and that Surface is now a card in a channel. Nothing was breached. The permissions worked as configured. The data still reached forty people because the person who built it could see it and the channel could see them.

The question to ask before you turn it loose

The build is bounded by the builder’s permissions. The sharing is bounded by the channel. Those are not the same boundary.

Whether a viewer’s own access gets re-checked when they open a Surface someone else posted is a thing to verify for your own configuration before you rely on it, not to assume. Design as if a posted Surface shows its full contents to everyone in the channel, because for a snapshot, it does.

So the governance work is not new, but it moves. Two things to get right:

  • Your sharing model has to be real, not aspirational. Every over-broad profile becomes a Surface someone can build and post. Run the org health scorecard or your own audit and close the gaps between what people can see and what their job needs.
  • Channel hygiene becomes data hygiene. A Surface built from CRM data is only as private as the least-restricted person in the channel it is posted to. Sensitive Surfaces belong in scoped channels or DMs, and that is a norm you have to set, because Slackbot will not set it for you.

For the metric-shaped questions, there is a second reason to care about grounding. A Surface that computes “revenue” or “win rate” is only right if it uses your definition of those terms. Point Slackbot at raw objects and it will guess at the calculation the same way any agent does. Grounding it on a semantic layer is what stops a channel-wide dashboard from stating a confident, wrong number, and it is the same discipline that keeps Tableau Next honest.

Where a Surface is the wrong tool

A generated Surface is a genuine win for a fast, disposable, “show me X right now” view. A Surface is the wrong tool for the dashboard your whole company runs on every morning. A governed, versioned, access-controlled report built in Tableau or native Salesforce reporting is auditable and consistent in a way a prompt-built card is not, and you want that for the numbers that drive decisions.

The pattern that works: let Surfaces absorb the long tail of one-off requests, the questions that used to become a Slack DM to an analyst, and keep your governed reporting for the metrics of record. Do not let a Surface someone built in a channel drift into the number a quarterly review runs on, because it was never built to carry that weight.

If your team adopts this, the useful move is not to block it, because you will lose that fight, and the low plan bar means it is already in your workspace. The move is to fix the permission model underneath it so that whatever anyone builds is bounded by what they were always allowed to see, and to set the norm that sensitive Surfaces live in scoped channels. Get those two right and Slackforce Surfaces is a real productivity gain. Skip them and it is a data-exposure surface with a friendly prompt.

Understanding the basics

What is Slackforce Surfaces?

Slackforce Surfaces is a Slack feature, announced at Dreamforce 2026, that lets a user describe a dashboard, report, deck, poll, or microsite in plain language and have Slackbot build it inside a Slack conversation. Surfaces are grounded in real-time data from Slack and connected apps such as Salesforce and Google Drive, and they are one of the three interfaces under Salesforce’s AIforce layer.

What data can a Slackforce Surface show?

Only data the person building it is already permitted to access. Slackbot uses the Salesforce data the requesting user can see, subject to the permissions granted to Slack’s AI tools, so your Salesforce sharing rules and field-level security bound what any Surface can display.

Does a Slackforce Surface update automatically?

Not until live-data support arrives, which Salesforce dated to October 2026. Before that, a Surface is a snapshot from the moment it was built, so a dashboard pinned to a channel reflects the data as of its build time rather than the current state.

How much does Slackforce Surfaces cost?

Slackforce Surfaces is available to workspaces with Slackbot enabled across Enterprise+, Business+, Pro, Legacy, and Free tiers. Salesforce positioned the low plan bar as deliberate. Consumption tied to Agentforce and Data 360 capabilities is still billed through the usual Flex Credit model.

If your workspace is about to fill with Surfaces

The way to make this safe is to fix the permission model before the tool spreads, not after. If you want a second pair of eyes on whether your Salesforce sharing rules and channel norms can hold up when anyone can build a dashboard from a sentence, talk to us, or start with the Agentforce readiness assessment.

Keep reading

All insights