Slack — what to enable, and who it exposes

Slack is connected per project, and each connected channel is set up separately. That matters more than it sounds: Slack has no per-person permissions we can see. Everyone in the channel receives everything sent there, and can run anything you enable — including people invited months after you set it up, and including your client if it is a shared channel.

So the question is never "can this person do this". It is "can anyone who is, or ever will be, in this room".

Who this is for

Agencies who live in Slack and would rather type there than open another tab. If your team already runs client work in per-client channels, this fits that shape: one channel, one project.

The three things you can turn on

Each is separate, because they go wrong in different ways.

Notifications

Alerts posted into the channel — content changes and task updates today.

What it exposes: everyone in the channel sees them. In a shared client channel, that means the client learns about a problem at the same moment you do, before you have read it or decided what it means. Fine for a "post published" note. Less fine for a ranking drop.

Leave off for client-facing channels unless you are comfortable with unreviewed news reaching them.

Actions

Running work from Slack: /xavier audit starts a real site crawl.

What it exposes: anyone in the channel can spend your credits. A crawl is billed work, and Slack does not tell us who is allowed to start one — only who typed it.

Leave off for any channel a client or contractor is in.

Asking Xavier

Free-form questions to the agent from inside Slack.

Off by default, and the only one that starts that way. The other two do a fixed thing; this one answers whatever is asked, and spends credits doing it. A stray question in a busy channel is a real charge.

What it can and cannot do. It answers from data already stored — rankings, the last audit, Search Console, AI visibility. It cannot run, publish, or change anything, and it will say so if asked to. Starting work stays behind /xavier audit, which has its own switch, because a message written by whoever is in the channel is a question to answer and never an instruction to follow.

Connecting your workspace

Press Add to Slack under Publishing → Slack. Slack asks which workspace and shows what the app is allowed to do, you approve, and you land back where you started.

You do not create a Slack app, and there is nothing to paste. The three permissions requested are the whole list:

• app_mentions:read — messages that say @Xavier, and only those. Not channel history.
• chat:write — posting replies and alerts.
• commands — receiving /xavier.

Nothing here can read a channel you have not addressed the bot in, list who is in it, or open its files.

One workspace connects to one PageOptimized organization. Adding it again from a different organization moves it rather than connecting it twice.

Two connections, not one

Posting into Slack and being typed at in Slack are separate, and a connection can have one without the other.

An incoming webhook is a one-way URL. Slack binds it to a channel when you create it and never tells us which channel that is — so there is no way to recognise a message arriving from there. Notifications work; nothing else can.

Add to Slack does both and is what almost everyone wants. The webhook and bot-token fields below it are for connecting a channel by hand — useful if your workspace will not let you install apps, or if you only want alerts posted somewhere. If you only want alerts, a webhook is the simpler thing and there is nothing missing. The other two switches are greyed out and say why.

To answer questions and run work, the channel needs its ID recorded. The quickest way is to run /xavier use project Acme in the channel itself — it fills the ID in for you. You can also paste it into the Channel ID field on the connection page; it starts with C, and it is not the channel name. The Channel label beside it is only there to read on the settings page, and putting a name in the ID field is the one way to make the switches lie: they will read as on and nothing will happen.

Setting a channel up

1. Add to Slack under Publishing → Slack, once per workspace
2. Invite the bot to the channel: /invite @Xavier
3. In the channel, run /xavier use project Acme to map it to a project
4. Choose which of the three to enable for that channel

Steps 2 to 4 repeat per channel. Step 1 does not.

Commands for finding and mapping projects — /xavier projects, /xavier use project — always work. Otherwise a channel with everything switched off would have no way to fix its own configuration from Slack.

Commands

Slash commands do not work inside threads. Slack only runs its own built-in commands there, so /xavier ... in a thread answers "not supported in threads" — that is Slack refusing, not the app failing. Mention @Xavier instead: mentions work anywhere, and one asked inside a thread is answered in that thread.

Slack does not autocomplete these. Typing /xavier shows the usage hint from the app, and /xavier help lists everything.

A rule worth adopting

One channel per client, and decide before you invite them. Changing the setting later does not unsend anything, and a client who has seen the alerts will ask why they stopped.

Internal channels are where actions belong. Client channels are where a curated client portal belongs — it shows exactly what you chose, and nothing arrives there unreviewed.

Turning it off

Switch any capability off under Publishing → Slack and it stops immediately. Removing the channel mapping stops everything for that channel at once.

Next

• Sharing a client portal
• Credit budgets
• People and access