Your team lives in Slack. Your systems don't.

Watch where the day actually happens in your company. Someone asks whether the order shipped. Someone else opens the back office, looks, and types the answer into a channel. A third person asks the same thing two hours later.

The answer existed the whole time. It was just somewhere nobody was.

That gap has a cost, and everyone has quietly agreed to live with it, because closing it used to mean asking people to work in two places at once. That is the part that changed.

Salesforce launched Slack Code and dedicated code channels. Tag a coding agent in a conversation and it opens a working space right there: the discussion, the agent's plan, the changes it made, and a live preview of the result running. It works with Claude Code, Devin, GitHub Copilot, ChatGPT, and Vercel agents.

The headline is about developers. The more interesting part sits underneath it, and it is not new. Slack has been building the plumbing that lets outside systems and agents work with what is happening in a channel, and Anthropic, Google, Notion, Dropbox, Perplexity and others have been building on it since late last year.

Read together, those two things say something simple. Slack has stopped being the place where people talk about the work and started becoming a place where the work can happen.

The examples below are ours rather than Salesforce's, so treat them as a starting list and not a feature list. Each one is the same move: take something that currently requires a person to go and look, and let it arrive instead.

Approvals where the conversation already is. A customer requests a change in your portal. Today somebody notices it, screenshots it, and pastes it into a channel to ask what to do. Instead the request itself lands in the channel that owns it, with the customer's history attached and two buttons on it. The decision gets made where it was going to be discussed anyway, and the system records who made it.

Exceptions that announce themselves. Every operational system has a happy path and a set of cases that fall out of it. Those exceptions usually surface when somebody chases an order, which means the delay is already three days old. An exception can post itself into the channel of the team that owns it, at the moment it happens, with enough context to act on.

The number arrives instead of being fetched. Most companies have dashboards almost nobody opens. The weekly figure that would actually change a conversation can be posted into the channel where that conversation happens, on the morning it matters, with the two lines of context that make it mean something.

Onboarding that runs itself. A new client signs. Today that triggers a checklist somebody owns and half remembers. Instead the channel gets created, the tasks appear as they become due, and each one closes when the underlying system says it is done rather than when somebody ticks a box.

Questions answered from your own material. An agent working in a channel can draw on what is around it. "What did we agree with this client about their renewal" is a question your team currently answers by searching three tools and asking whoever was there.

Handovers that stop losing things. Work that crosses two teams usually crosses two systems, and the context does not survive the trip. Sales agrees something, delivery finds out later, and the detail that mattered was in a thread nobody thought to forward. A handover can move as one object, carrying the record and the conversation together into the channel that picks it up.

Changes started by whoever noticed. This is the Slack Code piece. The person who spots a typo on a pricing page, or a broken link, can start the fix from the conversation where they noticed it, and the team watches it happen rather than reading about it afterwards.

One decision comes with this, and it is worth making before you switch anything on.

Slack's permissions were built to answer who can read a channel. They were not built to answer who can approve a refund or change a live page. When systems arrive in Slack, those two questions meet for the first time.

So write down who may trigger what, and who may approve it, by role rather than by whoever happens to be in the channel. It is an afternoon of work, and it is the difference between a capability and an incident.

Not with the integration. Start with a list of the questions your team asks each other most often that a system already knows the answer to. Where did this order stop. Has the client replied. Is this deployed. Did that invoice go out.

Every one of those is a signal your systems already hold and your people currently fetch by hand. That list is your integration backlog, in priority order, and you can write it in twenty minutes without talking to a vendor.

Then take the top one only. A single question, answered automatically in the place it gets asked, is a small piece of work with a visible result, and it tells you more about whether this is worth doing than any amount of planning will.

We build the systems this connects to: back office platforms, client portals, dashboards, and approval workflows, including scoped permissions across hundreds of editors. What is changing is not what those systems do. It is that they no longer have to wait to be visited.

The interesting question stopped being which tools you own. It is which of them can reach your team without being opened.