Slackforce and Slack Code: Define Agent Boundaries

Slack’s Dreamforce announcement presents Slackforce as a way to bring Salesforce data into conversations and Slack Code as a shared space for people and coding agents; it lists Surfaces and Slack Code as available, subject to rollout and licensing, while Slackbot in channels is an early pilot. A request to Slackbot can produce an interactive Surface, and a Slack Code channel can show a team an agent’s plan, proposed code diff and working preview. These are related workflows, but they do not give every agent the same access or authority.

TechRadar’s Dreamforce coverage describes Slackforce as an intelligent layer for the platform and Slack Code as a way for teams to code and create together. The practical change is that a conversation can lead to a shared view of customer data, a proposed record change or a code review. That is the sense in which the conversation becomes executable: the request can move into work with consequences outside the thread. An administrator needs to define which data and actions each agent may reach before treating the channel as a safe place to start that work.

What changes when Salesforce data becomes a Surface

A Slackforce Surface is a shared working view rather than an answer pasted into a thread. Slackbot can build a dashboard, report or other interactive view from a request using connected information, including Salesforce data from Sales Cloud, Service Cloud, Data 360 or Tableau. Teammates can filter, explore and comment on a Surface, then pin it to a channel. A pinned Surface stays connected to its source, so the channel becomes a destination for information that may also exist in a more restricted system.

That destination needs its own access decision. A person authorized to ask about a customer record may belong to a channel with a broader or changing audience. Before pinning a Surface, identify the records and fields it may expose, who can enter the channel, and what a new or departing member can see. Check the behavior in the actual workspace rather than assuming that the permissions governing a Slackbot answer settle every question about a shared view. Keep permission to display information separate from permission to change the underlying record.

What Slack Code changes for a development team

Slack Code gives an agent-assisted coding session a shared channel. Teammates can see the agent’s plan, inspect a diff and preview the result in the conversation. For higher-stakes work such as a production push, the announced workflow packages the agent’s work for a teammate’s sign-off. The channel makes review visible to more of the team, but the connected coding tools still determine what the agent can do in a repository or deployment environment.

Define those tool permissions separately. Reading a repository, creating a branch, proposing a change, merging code and deploying it are different grants of authority. A visible discussion does not establish that a connected agent has only the permissions the participants intended. The reviewer also needs enough information to judge the proposed change: the diff, the preview where one exists, the target environment and the action that approval will permit. The central boundary is between an agent proposing work and an agent being able to ship it.

A permission-and-data-flow worksheet

Slack’s Salesforce administration guidance says Slackbot can find information in connected Salesforce organizations and can create or update records by default; administrators can restrict organizations and record actions, Salesforce permissions limit what appears in a user’s response, and members are prompted to review and approve record changes. Those controls address CRM access, but they do not define permissions for every coding tool connected to a channel. For each proposed workflow, record an owner and a way to check these boundaries:

Channel access: Name the channels where an agent may participate, who can add it and who can join later. Record whether the channel capability is available under the workspace’s rollout and licensing conditions.
Salesforce records: List the connected organizations, permitted objects and fields that may enter the workflow. Identify whose Salesforce permissions govern a request and whether the agent needs read access or a narrowly defined record action.
Agent actions: Distinguish answering, drafting, posting, creating a record, updating one and invoking another tool. Assign an administrator or tool owner who can grant and revoke each capability.
Coding sessions: Specify the repositories, branches, preview environments and agents in scope. State whether an agent may propose a diff, open a review, merge code or deploy it.
Retained context: Identify where prompts, channel history, record excerpts, code snippets and pinned Surfaces may remain. Establish the applicable retention and deletion rule for each system; do not assume the channel transcript is the only copy.
Approvals: Name the reviewer for a Salesforce write, a sensitive shared Surface, a code merge and a production release. State what that reviewer can inspect and which action their approval authorizes.
Audit trail: Identify where the request, agent action, human approval and resulting CRM or code change are recorded. Check whether those records let an administrator reconstruct the sequence across systems.

This worksheet is a policy design, not a single Slack setting. A Salesforce record action and a repository action cross different permission boundaries, even when both begin in the same conversation. The useful unit of review is the complete path from a person’s request through the agent’s tools to the resulting change.

Stage adoption around a traceable action

Start with a channel and Salesforce organization whose participants and records are understood. Have users with different access rights request the same type of Surface, then inspect what each receives and what appears after a view is pinned. Check the audience again after a membership change. Only then consider a narrowly permitted record update, including the approval prompt and the resulting record change.

For Slack Code, begin in a repository and preview environment where a reviewer can inspect a proposed diff without giving the agent production authority. Trace which connected tool performed each step and where its evidence remains. The adoption decision is ready when the worksheet identifies the requester, the information an agent may read, the actions it may take, the human who approves a consequential change and the records needed to reconstruct that change afterward.