Connected Services and Permissions Disclosure
Effective May 16, 2026 · Avalon Flow Inc., a subsidiary of Questili LLP · support@avalonflow.com
For this policy, "Avalon," "we," "us," or "our" means Avalon Flow Inc., a subsidiary of Questili LLP, unless a signed order form or customer agreement identifies a different contracting entity.
This disclosure explains why Avalon requests permissions for connected services such as Google APIs/Gmail, Google Calendar, Google Drive where enabled, Microsoft Graph/Outlook, calendars, Slack, Salesforce via MCP, MCP connectors, custom endpoints, and AI providers.
Avalon should use least-privilege permissions appropriate for the customer workflow. Some features require broader read/write permissions because Avalon operates on email, calendar, drafts, labels/categories, sends, or connected workflow actions.
1. Google/Gmail permissions
Depending on enabled features, Avalon may request Google permissions for:
| Permission area | Why Avalon may need it | Risk and control |
|---|---|---|
| Sign in and profile | Authenticate users and identify connected Google accounts | Required for account access |
| Offline access / refresh tokens | Keep sync and background workflows working after sign-in | Protect tokens and allow disconnect/revoke |
| Gmail read | Read message metadata and content for Flowboard, summaries, search, due dates, briefs, and context | Sensitive inbox access; connect only authorized mailboxes |
| Gmail modify / labels | Apply labels, update read/action state, organize mail, and manage mailbox actions where enabled | Mutating access; use approval and audit where practical |
| Gmail send / drafts | Draft or send messages when the user approves or configures a workflow | High-risk permission; human approval should be clear |
| Google Calendar read | Read events, availability, and meeting context for briefs and scheduling | Sensitive calendar access; minimize use to enabled features |
| Google Calendar write | Create or update calendar events where enabled | Mutating access; confirm before material changes |
| Google Drive, if enabled | Preview, file, or attach selected workspace materials for approved workflows | Sensitive file access; scope to enabled workflows |
| Google Pub/Sub | Receive Gmail change notifications for sync and background processing | Operational access; protect verification tokens and subscription endpoints |
Avalon does not use Google account data for advertising.
2. Microsoft Graph and Outlook permissions
Depending on enabled features, Avalon may request Microsoft permissions for:
| Permission area | Why Avalon may need it | Risk and control |
|---|---|---|
| Sign in and profile | Authenticate users and identify connected accounts | Required for account access |
| Offline access / refresh tokens | Keep sync and background workflows working after sign-in | Protect tokens and allow disconnect/revoke |
| Mail read | Read message metadata and content for Flowboard, summaries, search, due dates, briefs, and context | Sensitive inbox access; connect only authorized mailboxes |
| Mail read/write | Apply categories/folders, mark state, prepare workflow changes, manage mailbox actions where enabled | Mutating access; use approval and audit where practical |
| Mail send | Send or draft/send messages when the user approves or configures a workflow | High-risk permission; human approval should be clear |
| Calendar read | Read events, availability, and meeting context for briefs and scheduling | Sensitive calendar access; minimize use to enabled features |
| Calendar read/write | Create or update calendar events where enabled | Mutating access; confirm before material changes |
| User read | Identify the signed-in Microsoft account | Required for account linking |
Avalon does not use Microsoft account data for advertising.
3. Least-privilege posture
Avalon should request and use only permissions needed for enabled features and customer-approved workflows. Customers should review requested scopes before granting consent and should disable features, users, or integrations they do not need.
If a customer needs read-only or approval-only operation, the customer should configure Avalon and Google/Microsoft permissions accordingly where supported. Some features may not work without write-capable permissions.
4. Slack permissions
If Slack is connected, Avalon may need permissions to identify the Slack workspace/user, receive DMs or mentions, post replies or notifications, and support approved workflow prompts. Slack channel content may be visible to workspace admins, channel members, exports, retention tooling, legal holds, and Slack Connect participants.
Sensitive details should be reviewed before posting into Slack. For sensitive or destructive actions, Avalon should deep-link users back to Avalon for confirmation where practical.
5. Salesforce and MCP permissions
Salesforce via MCP and other MCP connectors may expose read or write tools depending on customer configuration. Customers are responsible for selecting MCP servers, scopes, tool permissions, records, environments, and approval rules.
Write-capable CRM or tool actions should be tested on sandbox or non-production records first and should require human approval unless the customer has expressly configured a narrow approved workflow.
6. Custom endpoints and webhooks
Custom endpoints can receive Customer Content, AI context, workflow payloads, or action requests. Customers are responsible for endpoint ownership, authentication, authorization, TLS, signing secrets, IP/network restrictions, logging, retention, input validation, output validation, and rollback.
Avalon may disable endpoints that create security, privacy, legal, operational, or abuse risk.
7. AI providers, local models, and BYO model routes
AI providers, local models, BYO keys, private models, self-hosted inference, and custom AI endpoints may process prompts, email/calendar context, workflow context, and AI outputs. Customers are responsible for approving customer-controlled model routes and confirming licenses, data-use terms, logging, retention, security, and suitability.
More detail is available in the AI Model Provider Policy and Local Model / Customer-Controlled AI Risk Acknowledgement.
8. Disconnecting connected services
Customers can disconnect connected services through product controls where available or by contacting support@avalonflow.com. Disconnecting a service stops future access where supported, but it may not delete data already processed by Avalon or retained by the connected service.
9. Customer responsibilities
Customers are responsible for:
- granting only appropriate permissions;
- maintaining admin approval and user access controls;
- removing access when users leave or workflows end;
- complying with connected-service terms;
- reviewing AI outputs and external actions;
- reporting suspicious activity or permission concerns to support@avalonflow.com.
10. Contact
For questions about connected-service permissions, contact support@avalonflow.com.