Scout reads, it never writes
Every connection Scout makes is read-only. That is not a setting you could switch off by accident — it is how each connection is built, and in one case where the provider offers no read-only permission, it is enforced by an automated check that fails Scout's own build if a write request is ever added. This article names exactly what Scout asks for from each provider, and exactly what Scout produces of its own.
Screenshot: the Connections page states the rule at the top — Scout reads these sources and never owns the records. Your tools stay authoritative.
What Scout asks for, provider by provider
| Connection | What Scout asks for | What that means it can read |
|---|---|---|
| Gmail / Google Workspace | The read-only Gmail permission (gmail.readonly), and nothing else. |
Inbox and Sent messages, participants, threads, and attachment details. Scout cannot send, reply, draft into your mailbox, label, archive, or delete. |
| Microsoft 365 / Outlook (personal mailbox) | Mail.Read, plus the permission that lets Scout keep reading without asking you to sign in again (offline_access). |
Outlook and Exchange messages, folders, participants, threads, and attachment details. No send, no write, no calendar, no contacts, no files. |
| Microsoft 365 (named shared mailbox) | A separate application identity with no organization-wide mail permission. Your Exchange administrator scopes read access to the one named mailbox using Exchange's role-based access for applications. | Only the mailbox your administrator named. Scout proves at setup time that it can read that mailbox and cannot read an unrelated one before the connection is created. |
| QuickBooks Online | The accounting permission (com.intuit.quickbooks.accounting). Intuit publishes no read-only version of it. |
Customers, estimates, invoices, bills, payments, and credit memos. Because the provider cannot narrow the permission, Scout narrows itself: an automated check permits only read requests and the token exchange, and blocks the build if any other request path appears. |
| Slack | Four permissions: send a message, register the /scout command, read the member directory, and read members' email addresses so it can match them to Scout accounts. |
Your member directory, so Scout can offer to link each person's Slack account to their Scout seat. Scout does not ask for channel history, direct-message history, files, or reactions — fifteen permission groups are explicitly forbidden in Scout's own Slack configuration. |
| Suppliers (PromoStandards) | Read-only requests only, against a fixed list of endpoints. | Open orders, ship notices, inventory, pricing, product data, and invoices. There is no purchase-order write path in Scout's supplier client at all, and an automated check proves it. |
Two further things are true of every connection:
- Scout reads through the provider's own consent screen. You see Google's, Microsoft's, or Intuit's own permission list before anything happens, and it will match the table above.
- Scout never sees your supplier passwords. Supplier credentials obtained on your behalf are held in your workspace's own account with the supplier data gateway; they pass through and are not stored by Scout.
What Scout produces of its own
"Read-only" describes how Scout treats your data. It does not mean Scout is silent. Scout authors four kinds of output, all of them clearly labeled as Scout's and all of them addressed to people inside your workspace:
- The morning brief — one email a day per person, sent from Scout's own domain. It never goes out through your mail grant.
- Notifications — item updates by email, and direct messages in Slack if you have linked your account. Again, only to people in your workspace.
- Notes and receipts — the close note you write, and the record Scout writes when it settles something on evidence.
- Prepared drafts — suggested wording for a message you might send, shown under Draft — prepared by Scout with a Copy draft button and a link to open the original thread in your own mail program.
That is the whole list. Scout prepares — you send.
What Scout will not do, in plain terms
- It will not send, reply to, delete, label, move, or file anything in your mailbox.
- It will not create, edit, void, or pay an invoice, apply a payment, or issue a credit memo in your accounting system.
- It will not place a purchase order, change one, cancel one, or acknowledge one. Purchase orders are read-only in Scout.
- It will not write to a customer record, a deal, or an opportunity anywhere.
- It will not contact your customers or your suppliers. Sending to an outside party is your action, from your mailbox, in your name. Order-status updates sent to your customers on your behalf are not available today.
- It will not post in a Slack channel. Scout's Slack messages are direct messages to the person they concern.
What happens when Scout closes an item for you
Scout does settle items on its own, and that is worth being precise about, because it is the one place Scout acts without being asked. When the evidence a point was waiting for arrives — the reply lands, the invoice clears, the supplier acknowledges the purchase order — Scout marks the item settled, writes a receipt naming the evidence that settled it, and notifies the people working it so nobody does the work twice.
Nothing outside Scout changed. Scout updated its own list.
Good to know
- Scout stores what it read so it can notice change. That copy lives inside your workspace and is never shared across workspaces.
- A link into a provider record — "Open in Gmail", a QuickBooks deep link — only appears when Scout has proved the link points at the exact account and record it says it does. If it cannot prove that, there is no link rather than a guess.
- Revoking a connection destroys Scout's stored authorization and withdraws its access. See Removing a connection or leaving Scout.
- The legal version of everything on this page is in the Privacy Policy and the Terms of Service.