What permissions Syncline asks for

<h2>The rule we work to</h2><p>Syncline asks for the narrowest scope that lets a flow do its job, and it asks at connection time rather than quietly later. If you add an action that needs more access than the connection has, the builder tells you before you save and sends you back through a re-approval. No scope is ever added behind your back.</p><p>Two consequences follow. A read only connection is a real option, and plenty of teams run one for months. And a flow that only posts messages never gains the ability to read history, because the scope for reading was never granted.</p><h2>What each app asks for</h2><table><thead><tr><th>App</th><th>Scopes requested</th><th>What this does not include</th></tr></thead><tbody><tr><td>Notion</td><td>Read and write on the pages you share</td><td>Any page outside your selection</td></tr><tr><td>Slack</td><td>Read selected channels, post messages, add reactions</td><td>Direct messages, private channels we were not invited to</td></tr><tr><td>Gmail</td><td>Read messages matching your search, send, modify labels</td><td>Contacts, Drive, calendar, mail outside the search</td></tr><tr><td>HubSpot</td><td>Contacts, deals, forms on one portal</td><td>Other portals, marketing email sending</td></tr><tr><td>Airtable</td><td>Read and write on the bases you tick</td><td>Bases left unticked, workspace administration</td></tr><tr><td>Trello</td><td>Read and write on boards your account can see</td><td>Boards in other Trello workspaces</td></tr><tr><td>Stripe</td><td>Read charges, customers, subscriptions</td><td>Payouts, balance transfers, refunds unless a flow adds that action</td></tr></tbody></table><blockquote><p>Note: for Gmail, the search string is applied on Google's side. Mail that does not match your search is never returned to Syncline in the first place, so it cannot be stored, logged or read by our support team.</p></blockquote><h2>Narrowing access after setup</h2><p>You can tighten a connection at any time, and you do it at the provider rather than here. Work through it in this order so nothing breaks quietly.</p><ol><li><strong>List what the connection is actually used for.</strong> Open Settings, then Connections, and read the flow count beside the account. Clicking it names each flow.</li><li><strong>Remove the resources none of those flows touch.</strong> In Notion, open the page and use <em>Connections</em> to drop Syncline. In Airtable, edit the token's base list. In Slack, remove the app from the channel.</li><li><strong>Run a test on each affected flow.</strong> The builder reads one record, which is enough to prove the remaining access still covers the job.</li><li><strong>Check the run history the next morning.</strong> A resource removed by mistake shows up as a single clear failure naming what it could not reach.</li></ol><p>When a flow reaches for something it can no longer see, it fails with a message naming the resource rather than silently writing nothing. That is by design: a quiet flow is worse than a loud one.</p><h3>What we never ask for</h3><p>We do not request the ability to delete records in any of the seven apps. We do not ask for admin scopes, billing access on your provider accounts, or the right to add and remove users. Stripe write access covering payouts and balance transfers is not in the list and never will be, and the refund action is opt in per flow.</p><p>Tokens are encrypted at rest with a per workspace key and are never written to logs. Support staff can see that a connection exists and whether it is healthy, and cannot read the token itself.</p>