Log inApply for Beta
Back to home

Data & Permissions

What each provider connection is for.

TAO requests provider access only when a user or administrator connects that provider, and only for features that are visible inside the product.

Last updated: May 22, 2026

Provider permission map

This page is the public permission disclosure used by reviewers, administrators, and customers. It should stay aligned with actual OAuth consent screens, provider scopes, and in-product connection flows.

Google Workspace

Connection
OAuth 2.0 through a reviewed Google project.
Data
Gmail, Google Calendar, Contacts, Directory, and Drive data only where the connected feature and approved scope require it. Restricted Gmail/Drive scopes require Google verification and a Limited Use commitment.
Status
Email and calendar provider connection paths exist; broader Workspace or Drive access must be reviewed before activation.
Controls
Users can disconnect in TAO and revoke access from their Google Account. TAO's use and transfer of Google user data adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Microsoft 365 and OneDrive

Connection
Microsoft Entra ID OAuth/OpenID Connect and Microsoft Graph permissions. Publisher verification configured before enterprise rollout.
Data
Outlook mail, calendar, profile, files, and organisation context only where an admin or user grants the relevant Graph permission.
Status
Email and calendar provider connection paths exist; identity sign-in and OneDrive file access require dedicated reviewed app registration settings.
Controls
Admins may require consent for high-privilege Graph permissions. TAO uses verified publisher/domain settings before enterprise rollout.

Xero

Connection
Xero OAuth 2.0 with granular scopes (post-March 2026 ecosystem requirement).
Data
Invoices, contacts, payments, account codes, journals, and reports only when the Xero workflow needs them. We request the narrowest granular scopes that cover the live feature.
Status
Granular scopes requested: offline_access, accounting.transactions, accounting.contacts, accounting.settings.read, accounting.reports.read, accounting.journals.read. Payroll, files, assets, and bank-feeds scopes are not requested unless the customer explicitly enables those workflows.
Controls
TAO handles insufficient-scope errors and prompts re-authorisation when scopes change. Disconnect or re-authorise from Xero at any time.

Current RMS

Connection
Current RMS OAuth2 or API key authentication depending on the customer setup.
Data
Operational records such as members, contacts, jobs, opportunities, inventory, and rental data where the implementation scope requires it.
Status
Current RMS is treated as an operational integration path for implementation planning and credential disclosure.
Controls
API keys have broad read/write access and must be encrypted, rotated, and revoked when no longer needed.

QuickBooks and other systems

Connection
Provider-specific OAuth or API credentials after implementation review.
Data
Finance, CRM, communication, and operational data only after the exact provider contract and scopes are documented.
Status
Planned integration path.
Controls
No future provider scope is requested until the user-facing feature exists and the public disclosure on this page is updated to match.

OAuth review checklist

  • Use a production OAuth project or app registration separate from test projects.
  • Keep homepage, privacy policy, terms, support email, app name, logo, and authorised domains consistent with the provider consent screen.
  • Request only scopes needed by live user-facing features, and document why narrower scopes are not enough.
  • Keep redirect URIs and JavaScript origins on owned HTTPS domains.
  • Prepare reviewer test credentials and a demo video showing the OAuth grant, consent screen, and where each sensitive or restricted scope is used.
  • For Google restricted scopes such as broad Gmail or Drive access, complete the required Google verification and security assessment before broad production use.
  • For Microsoft multi-tenant apps, configure publisher/domain verification and expect admin consent for high-privilege Graph permissions.
  • For Xero, use granular scopes as available and prompt users to re-authorise when the scope set changes.

Reviewer pack — what we submit to each provider

The following identifiers and URLs are the canonical ones TAO uses on every provider consent screen and developer-portal submission. They match this page so reviewers can verify alignment quickly.

App name
TAO — The Artificial Organisation
Primary domain
theartificialorganisation.com
App subdomain
app.theartificialorganisation.com
API subdomain
api.theartificialorganisation.com

Button and naming rules

TAO should only show active Google or Microsoft sign-in buttons when the corresponding identity login flow is implemented and configured. Provider connection buttons should describe the provider being connected without implying endorsement.

  • Google identity buttons should use the official Sign in with Google, Sign up with Google, or Continue with Google pattern and preserve the Google G logo rules.
  • Microsoft identity buttons should use Sign in with Microsoft and refer to work or school accounts where needed.
  • Do not call Microsoft accounts Azure ID, Microsoft 365 ID, enterprise account, business account, or corporate account in end-user sign-in copy.
  • Do not use provider logos as TAO branding or imply that Google, Microsoft, Xero, Current RMS, or QuickBooks endorses TAO.
Sign inApply for Beta