Stria and Slack

Scope checks on the channels you nominate — and a consent screen with four scopes on it.

Plans: Available on every plan. Connecting requires workspace admin rights. See plans and pricing

Client requests do not only arrive by email. In a shared Slack channel, "while you're in there,

could you also…" reads as conversation rather than a change of scope, and it is gone by the time you

next open the agreement. Connecting Slack lets Stria check the channels you nominate against the

scope your client signed.

The four scopes it asks for

Slack's own consent screen is the authority here, but it should hold no surprises:

Scope	What it grants
`channels:history`	Read messages in public channels it has been added to
`groups:history`	Read messages in private channels it has been added to
`channels:read`	List public channels, so you can pick one by name
`groups:read`	List private channels, for the same reason

Two read scopes and two list scopes. Read what it can see, name what it can list — nothing else.

This list matters more than the one above, because a scope you were never asked for is one you

cannot accidentally grant.

Refused	Why
`chat:write`	Would let Stria post into your Slack. It never needs to — findings appear in Stria, and nothing is written back to a channel or sent to a client.
`search:read`	Would let Stria search the whole workspace. Slack names it among the scopes granting extensive access without clear need, and a channel that receives events has no use for search.
`users:read.email`	Would read every workspace member's email so a sender could be matched to a client automatically. You tell Stria which client a channel is about instead.
`files:read`	Would read files shared in the channel. Only message text is examined.

There is no write scope of any kind. Stria cannot post, react, rename, invite, or send a direct

message, and no configuration changes that.

A private direct message between you and your client is not reachable. Not at these scopes and

not at any others — a Slack bot token does not cover another person's DMs, so no scope request would

change it. If the expensive requests arrive in a DM, forwarding the message is the route, not this.

Group DMs are joinable in principle and are not included in the initial grant, which is why the

consent screen lists four scopes rather than six.

In Settings → Integrations, start the Slack connection. Slack's consent screen lists exactly what

is about to be requested.

Nominate the channels Stria may read. This is an allow-list — nothing is read until you name a

channel, and adding the app to a channel is a separate act from installing it.

Associate each nominated channel with a client, so a request has a scope to be checked against.
Lock a scope baseline for that client if you have not already. Without one there is nothing to

check against, and this is the most common reason detection looks silent.

Scope checks are metered as AI actions, and Slack detection is metered daily as well as monthly —

because how much a client sends you is not your decision. Messages that are plainly not requests are

filtered before any allowance is spent, and a message that cannot be matched to a client costs

nothing rather than being checked against a guess.

You do not have to. Forwarding a client message gives you the same check with no OAuth grant at all.

When detection is on but nothing is appearing, the four checks in order

covers it.

Stria and Stripe — Your Stripe account, your money, your merchant relationship — Stria issues the invoice.
Stria and Xero — Invoices and payments pushed to your ledger, and reconciliation read back.
Stria and QuickBooks Online — Invoices and payments pushed to your ledger, and reconciliation read back.
Stria and Asana or Linear — Push an approved item to the tracker your team already works in. One way, one item at a time.
Webhooks and the API — Signed HTTPS events when work is approved or money moves, plus token-authenticated endpoints.