Atlas integrations setup

Public setup guidance for connector auth, scopes, mapping, sync behavior, webhooks, verification, troubleshooting, and rollback. Runtime connection health lives in Settings -> Integrations.

Auth boundary

OAuth, signed webhooks, SAML/SCIM, PAT, and BYOK keys stay credential-gated. This page lists names and scopes, not secret values.

Health boundary

Use Settings -> Integrations to view connected, disconnected, disabled, preview, retry, and sync-log state.

Privacy boundary

Docs and analytics must not contain provider account ids, OAuth codes, token prefixes, webhook URLs, or provider payload bodies.

Verification path

Every connector should be tested first in sandbox mode with scope review, callback validation, sync proof, and rollback rehearsal.

Sync evidence boundary

The hub can show local sync evidence rows, recent/stale posture, and blocked Gmail polling without returning provider objects, payloads, or live upstream responses.

Status definitions

Live

Runtime health can show connected or ready after configuration is complete.

Setup required

The adapter is production-shaped, but deployment configuration is required.

Preview contract

The setup, mapping, and health contract are visible before broad provider proof.

Adapter ready

Atlas has an admission/control-plane contract; sandbox or live proof is still gated.

Connector index

Live

Slack

Messaging

Live

GitHub App

Developer

Setup required

E-signature

Adapter ready

PandaDoc

E-signature

Adapter ready

Business ops

Priority connector families

Slack

Messaging command and notification routing.

Slack

Google Workspace

Workspace, Gmail, and Calendar setup paths.

Google Workspace Gmail Google Calendar

Gmail

Mailbox authorization, history, and disconnect readiness.

Gmail

Google Calendar

Calendar source, push, and write-back proof gates.

Google Calendar

Microsoft 365 / Outlook

Teams, Outlook, Calendar, and OneDrive readiness.

Microsoft 365 / Teams Microsoft Calendar OneDrive

Microsoft Teams

Teams collaboration under the Microsoft Graph setup path.

Microsoft 365 / Teams

Zoom

Meeting connector setup and webhook proof contract.

Zoom

Salesforce

CRM object sync and Growth Suite provider admission.

Salesforce Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

HubSpot

CRM timeline, pipeline, and workflow setup readiness.

HubSpot Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

Jira

Work-management issue mapping and signed webhook setup.

Jira

Linear

Team mapping, status, connect, disconnect, and sync-now contract.

Linear

GitHub

Repository installation, webhook, PR, and issue evidence.

GitHub App

GitLab

Merge request and project event proof gates.

GitLab

Notion

Workspace knowledge and database mapping readiness.

Notion

Confluence

Knowledge base indexing and permission mapping readiness.

Confluence

Dropbox

Storage OAuth, file metadata, and webhook setup.

Dropbox Dropbox, Box, OneDrive, Stripe

Box

Enterprise storage mapping and event proof gates.

Box Dropbox, Box, OneDrive, Stripe

OneDrive

Microsoft storage and Graph change notification setup.

OneDrive Dropbox, Box, OneDrive, Stripe

Stripe

Billing event destination, signature, and replay setup.

Stripe Dropbox, Box, OneDrive, Stripe

DocuSign

Envelope status, Connect callbacks, and audit proof gates.

DocuSign Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

Adobe Acrobat Sign

Agreement routing and PDF/e-sign provider admission.

Adobe Acrobat Sign Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

Dropbox Sign

E-signature workflow and callback setup readiness.

Dropbox Sign Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

PandaDoc

Contract template, signing, and document workflow readiness.

PandaDoc Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

OpenAI

AI provider activation via concrete no-key setup group.

AI Providers

Provider setup: OpenAI

Gemini

AI provider activation via concrete no-key setup group.

AI Providers

Provider setup: Gemini

Anthropic

AI provider activation via concrete no-key setup group.

AI Providers

Provider setup: Anthropic

Setup playbooks

Messaging

Slack

Events, slash commands, notifications, reminders, and Slack action routing.

Live

Auth method: OAuth 2.0 + signed events
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Event-driven with signed command/event callbacks.

Overview

Events, slash commands, notifications, reminders, and Slack action routing.

Prerequisites

Atlas owner/admin access
Slack provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Slack provider app in a sandbox workspace.
Configure the required deployment variables: SLACK_CLIENT_ID, SLACK_CLIENT_SECRET, SLACK_SIGNING_SECRET, SLACK_TOKEN_SECRET.
Grant only these scopes during authorization: commands, chat:write, channels:read, users:read.email.
Review local sync evidence readback in Settings -> Integrations; Atlas reports sampled local rows, recent/stale posture, latest evidence time, and privacy exclusions without upstream provider calls.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

SLACK_CLIENT_ID
SLACK_CLIENT_SECRET
SLACK_SIGNING_SECRET
SLACK_TOKEN_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

commands
chat:write
channels:read
users:read.email

Mapping behavior

Map provider workspaces, channels, users, slash commands, and message actions to Atlas notification and action-routing surfaces.

Sync direction

Bi-directional actions: provider events enter Atlas, and Atlas can send scoped notifications back to approved destinations.

Webhook details

Require signed event requests, timestamp freshness checks, fast acknowledgements, and replay-safe command handling.

Verification steps

Install in a sandbox workspace, run a slash command, confirm a notification delivery, and verify the event log shows no raw payload body.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for SLACK_CLIENT_ID, SLACK_CLIENT_SECRET, SLACK_SIGNING_SECRET, SLACK_TOKEN_SECRET.
Provider consent missing one of the required scopes: commands, chat:write, channels:read, users:read.email.
Local sync evidence readback shows no sampled rows, stale rows, disabled sync mode, or a blocked Gmail LABELED_SYNC poll receipt.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Slack is configured in the correct provider workspace or tenant.
Use local sync evidence readback to confirm Atlas-side event/link/message/checkpoint posture; it never returns provider object ids, task ids, endpoint URLs, payloads, message bodies, raw provider rows, or live upstream responses.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Treat local sync evidence as Atlas-side observability only; provider consoles, sandbox webhooks, and hosted telemetry remain required before claiming live provider delivery parity.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Slack command creates an Atlas work item, posts the assigned owner, and records a signed-event audit line.

Developer

GitHub App

Repository installation, webhook ingestion, task links, and PR/issue evidence.

Live

Auth method: GitHub App install + webhook HMAC
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Webhook-first with installation token refresh.

Overview

Repository installation, webhook ingestion, task links, and PR/issue evidence.

Prerequisites

Atlas owner/admin access
GitHub App provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the GitHub App provider app in a sandbox workspace.
Configure the required deployment variables: GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, GITHUB_APP_WEBHOOK_SECRET, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_SECRET.
Grant only these scopes during authorization: issues, pull_requests, metadata, webhooks.
Review local sync evidence readback in Settings -> Integrations; Atlas reports sampled local rows, recent/stale posture, latest evidence time, and privacy exclusions without upstream provider calls.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GITHUB_APP_ID
GITHUB_APP_PRIVATE_KEY
GITHUB_APP_WEBHOOK_SECRET
GITHUB_APP_CLIENT_ID
GITHUB_APP_CLIENT_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

issues
pull_requests
metadata
webhooks

Mapping behavior

Map organizations, repositories, projects, issues, merge requests, pull requests, branches, commits, pipelines, and installation owners to Atlas project evidence.

Sync direction

Mostly inbound evidence sync with outbound links, status references, and webhook-driven task updates.

Webhook details

Require provider signatures, installation or project scoping, retry logging, and idempotent event keys.

Verification steps

Connect a sandbox repository, open a test issue or merge request, and confirm Atlas records a normalized external reference only.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, GITHUB_APP_WEBHOOK_SECRET, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_SECRET.
Provider consent missing one of the required scopes: issues, pull_requests, metadata, webhooks.
Local sync evidence readback shows no sampled rows, stale rows, disabled sync mode, or a blocked Gmail LABELED_SYNC poll receipt.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm GitHub App is configured in the correct provider workspace or tenant.
Use local sync evidence readback to confirm Atlas-side event/link/message/checkpoint posture; it never returns provider object ids, task ids, endpoint URLs, payloads, message bodies, raw provider rows, or live upstream responses.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Treat local sync evidence as Atlas-side observability only; provider consoles, sandbox webhooks, and hosted telemetry remain required before claiming live provider delivery parity.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A repository issue links to an Atlas task, then a merge request update refreshes project evidence without exposing raw webhook payloads.

Gmail

Per-user OAuth, mailbox status, disconnect, token refresh, and safe callback handling.

Setup required

Auth method: Google OAuth delegated consent
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Per-user pull with revocation and hidden token columns.

Overview

Per-user OAuth, mailbox status, disconnect, token refresh, and safe callback handling.

Prerequisites

Atlas owner/admin access
Gmail provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Gmail provider app in a sandbox workspace.
Configure the required deployment variables: GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, GMAIL_REDIRECT_URI, GMAIL_TOKEN_SECRET, GMAIL_PUBSUB_TOPIC_NAME.
Grant only these scopes during authorization: openid, email, profile, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/gmail.modify.
Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.
Review local sync evidence readback in Settings -> Integrations; Atlas reports sampled local rows, recent/stale posture, latest evidence time, and privacy exclusions without upstream provider calls.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GMAIL_CLIENT_ID
GMAIL_CLIENT_SECRET
GMAIL_REDIRECT_URI
GMAIL_TOKEN_SECRET
GMAIL_PUBSUB_TOPIC_NAME
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

openid
email
profile
https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/gmail.modify

Mapping behavior

Map delegated mailbox identity, thread metadata, labels, and allowed message summaries to Atlas inbox and customer timeline records.

Sync direction

Per-user inbound pull; Atlas stores only scoped mailbox metadata required by the enabled workflow.

Webhook details

Use provider callback state verification and token-refresh audit logs; mailbox webhooks remain disabled unless explicitly configured.

Verification steps

Authorize a test mailbox, confirm the connection appears for the current user, then disconnect and verify revocation state.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, GMAIL_REDIRECT_URI, GMAIL_TOKEN_SECRET, GMAIL_PUBSUB_TOPIC_NAME.
Provider consent missing one of the required scopes: openid, email, profile, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/gmail.modify.
Local OAuth credential freshness shows refresh due, unknown expiry, or disabled rows that require reconnect review.
Local sync evidence readback shows no sampled rows, stale rows, disabled sync mode, or a blocked Gmail LABELED_SYNC poll receipt.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Gmail is configured in the correct provider workspace or tenant.
Use the OAuth credential freshness panel for local expiry and reconnect posture; it never calls the provider or returns tokens, authorization codes, account emails, provider account ids, or stored scopes.
Use local sync evidence readback to confirm Atlas-side event/link/message/checkpoint posture; it never returns provider object ids, task ids, endpoint URLs, payloads, message bodies, raw provider rows, or live upstream responses.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Refresh Settings -> Integrations and confirm the OAuth credential freshness panel shows no active local rows or an expected disabled/reconnect state.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Treat OAuth freshness as an Atlas-side local readback only; provider console logs remain the authority for provider-side token revocation events.
Treat local sync evidence as Atlas-side observability only; provider consoles, sandbox webhooks, and hosted telemetry remain required before claiming live provider delivery parity.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Gmail thread appears in the Atlas inbox, can be triaged into a customer task, and keeps the refresh-token value hidden.

Calendar

Google Calendar

Calendar OAuth, external event reads, planning overlays, and morning briefing context.

Live

Auth method: Google OAuth + PKCE
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: User-authorized read sync into planning surfaces.

Overview

Calendar OAuth, external event reads, planning overlays, and morning briefing context.

Prerequisites

Atlas owner/admin access
Google Calendar provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Google Calendar provider app in a sandbox workspace.
Configure the required deployment variables: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.
Grant only these scopes during authorization: calendar.readonly, openid, email, profile.
Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.
Review local sync evidence readback in Settings -> Integrations; Atlas reports sampled local rows, recent/stale posture, latest evidence time, and privacy exclusions without upstream provider calls.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GOOGLE_OAUTH_CLIENT_ID
GOOGLE_OAUTH_CLIENT_SECRET
CALENDAR_TOKEN_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

calendar.readonly
openid
email
profile

Mapping behavior

Map calendars, event ids, busy windows, attendees, titles where allowed, and recurrence metadata to planning overlays.

Sync direction

Per-user read sync for scheduling and availability; Atlas does not create events unless a workflow enables write scopes later.

Webhook details

Use OAuth state verification, refresh-token rotation, and provider watch channels only after admin approval.

Verification steps

Authorize a sandbox calendar, load the schedule overlay, confirm last sync time, and disconnect without leaving active watches.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.
Provider consent missing one of the required scopes: calendar.readonly, openid, email, profile.
Local OAuth credential freshness shows refresh due, unknown expiry, or disabled rows that require reconnect review.
Local sync evidence readback shows no sampled rows, stale rows, disabled sync mode, or a blocked Gmail LABELED_SYNC poll receipt.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Google Calendar is configured in the correct provider workspace or tenant.
Use the OAuth credential freshness panel for local expiry and reconnect posture; it never calls the provider or returns tokens, authorization codes, account emails, provider account ids, or stored scopes.
Use local sync evidence readback to confirm Atlas-side event/link/message/checkpoint posture; it never returns provider object ids, task ids, endpoint URLs, payloads, message bodies, raw provider rows, or live upstream responses.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Refresh Settings -> Integrations and confirm the OAuth credential freshness panel shows no active local rows or an expected disabled/reconnect state.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Treat OAuth freshness as an Atlas-side local readback only; provider console logs remain the authority for provider-side token revocation events.
Treat local sync evidence as Atlas-side observability only; provider consoles, sandbox webhooks, and hosted telemetry remain required before claiming live provider delivery parity.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A planning review reads external busy windows and protects the underlying calendar account and event identifiers.

Workspace suite

Google Workspace

Workspace-wide Gmail, Calendar, Drive, Docs, and admin-domain mapping setup for enterprise collaboration.

Preview contract

Auth method: Google OAuth + Workspace admin consent
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview Workspace mapping contract across mailbox, calendar, Drive, and document metadata.

Overview

Workspace-wide Gmail, Calendar, Drive, Docs, and admin-domain mapping setup for enterprise collaboration.

Prerequisites

Atlas owner/admin access
Google Workspace provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Google Workspace provider app in a sandbox workspace.
Configure the required deployment variables: GOOGLE_WORKSPACE_CLIENT_ID, GOOGLE_WORKSPACE_CLIENT_SECRET, GOOGLE_WORKSPACE_WEBHOOK_SECRET.
Grant only these scopes during authorization: openid, email, profile, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/calendar.readonly, https://www.googleapis.com/auth/drive.metadata.readonly.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GOOGLE_WORKSPACE_CLIENT_ID
GOOGLE_WORKSPACE_CLIENT_SECRET
GOOGLE_WORKSPACE_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

openid
email
profile
https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/calendar.readonly
https://www.googleapis.com/auth/drive.metadata.readonly

Mapping behavior

Map Workspace domains, users, groups, mailboxes, calendars, Drive folders, Docs metadata, and approved shared drives into Atlas planning and evidence surfaces.

Sync direction

Admin-approved inbound sync with per-surface consent; write actions stay disabled until a workflow explicitly requests and proves write scopes.

Webhook details

Use Google callback state verification, push-channel validation, expiration tracking, and renewal evidence before background sync is enabled.

Verification steps

Authorize a sandbox Workspace domain, approve one mailbox/calendar/Drive mapping, run dry sync, and verify the setup health panel returns sanitized object counts only.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GOOGLE_WORKSPACE_CLIENT_ID, GOOGLE_WORKSPACE_CLIENT_SECRET, GOOGLE_WORKSPACE_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: openid, email, profile, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/calendar.readonly, https://www.googleapis.com/auth/drive.metadata.readonly.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Google Workspace is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Workspace admin approves Drive metadata indexing so a project can link supporting Docs without exposing file contents or OAuth token details.

Calendar

Microsoft Calendar

Outlook calendar reads through Microsoft Graph for planning and availability.

Live

Auth method: Microsoft OAuth + PKCE
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: User-authorized read sync into planning surfaces.

Overview

Outlook calendar reads through Microsoft Graph for planning and availability.

Prerequisites

Atlas owner/admin access
Microsoft Calendar provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Microsoft Calendar provider app in a sandbox workspace.
Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.
Grant only these scopes during authorization: User.Read, Calendars.Read, offline_access.
Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.
Review local sync evidence readback in Settings -> Integrations; Atlas reports sampled local rows, recent/stale posture, latest evidence time, and privacy exclusions without upstream provider calls.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

MICROSOFT_OAUTH_CLIENT_ID
MICROSOFT_OAUTH_CLIENT_SECRET
CALENDAR_TOKEN_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

User.Read
Calendars.Read
offline_access

Mapping behavior

Map calendars, event ids, busy windows, attendees, titles where allowed, and recurrence metadata to planning overlays.

Sync direction

Per-user read sync for scheduling and availability; Atlas does not create events unless a workflow enables write scopes later.

Webhook details

Use OAuth state verification, refresh-token rotation, and provider watch channels only after admin approval.

Verification steps

Authorize a sandbox calendar, load the schedule overlay, confirm last sync time, and disconnect without leaving active watches.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.
Provider consent missing one of the required scopes: User.Read, Calendars.Read, offline_access.
Local OAuth credential freshness shows refresh due, unknown expiry, or disabled rows that require reconnect review.
Local sync evidence readback shows no sampled rows, stale rows, disabled sync mode, or a blocked Gmail LABELED_SYNC poll receipt.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Microsoft Calendar is configured in the correct provider workspace or tenant.
Use the OAuth credential freshness panel for local expiry and reconnect posture; it never calls the provider or returns tokens, authorization codes, account emails, provider account ids, or stored scopes.
Use local sync evidence readback to confirm Atlas-side event/link/message/checkpoint posture; it never returns provider object ids, task ids, endpoint URLs, payloads, message bodies, raw provider rows, or live upstream responses.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Refresh Settings -> Integrations and confirm the OAuth credential freshness panel shows no active local rows or an expected disabled/reconnect state.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Treat OAuth freshness as an Atlas-side local readback only; provider console logs remain the authority for provider-side token revocation events.
Treat local sync evidence as Atlas-side observability only; provider consoles, sandbox webhooks, and hosted telemetry remain required before claiming live provider delivery parity.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A planning review reads external busy windows and protects the underlying calendar account and event identifiers.

Work management

Linear

OAuth-backed Linear GraphQL issue and team operations through the shared connector store.

Live

Auth method: Linear OAuth / encrypted connector credentials
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Explicit GraphQL operations plus webhook verification; background task sync is scheduler-owned.

Overview

OAuth-backed Linear GraphQL issue and team operations through the shared connector store.

Prerequisites

Atlas owner/admin access
Linear provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Linear provider app in a sandbox workspace.
Configure the required deployment variables: LINEAR_CLIENT_ID, LINEAR_CLIENT_SECRET.
Grant only these scopes during authorization: read, write.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

LINEAR_CLIENT_ID
LINEAR_CLIENT_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

read
write

Mapping behavior

Map workspaces, teams, projects, issues, statuses, assignees, labels, milestones, and sprints into Atlas project intelligence.

Sync direction

Bi-directional only after mapping approval; preview mode remains inbound-first with explicit sync-now controls.

Webhook details

Validate provider webhooks, dedupe issue events, and keep external issue body text out of analytics payloads.

Verification steps

Connect a sandbox project, sync one issue, inspect mapping, and confirm retry logs show sanitized provider references.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for LINEAR_CLIENT_ID, LINEAR_CLIENT_SECRET.
Provider consent missing one of the required scopes: read, write.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Linear is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Jira issue maps to an Atlas project task, then a status change refreshes the delivery dashboard.

Collaboration

Microsoft 365 / Teams

Microsoft Graph OAuth, Outlook mail, and Teams read/write operations.

Live

Auth method: Microsoft Graph OAuth
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Explicit Graph operations plus subscription webhook verification; background sync is scheduler-owned.

Overview

Microsoft Graph OAuth, Outlook mail, and Teams read/write operations.

Prerequisites

Atlas owner/admin access
Microsoft 365 / Teams provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Microsoft 365 / Teams provider app in a sandbox workspace.
Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.
Grant only these scopes during authorization: offline_access, User.Read, Mail.Read, Mail.Send, Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All, ChannelMessage.Send, ChatMessage.Send.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

MICROSOFT_OAUTH_CLIENT_ID
MICROSOFT_OAUTH_CLIENT_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

offline_access
User.Read
Mail.Read
Mail.Send
Team.ReadBasic.All
Channel.ReadBasic.All
ChannelMessage.Read.All
ChannelMessage.Send
ChatMessage.Send

Mapping behavior

Map tenant, users, Teams, channels, mailboxes, and shared collaboration objects into Atlas communication and planning context.

Sync direction

Inbound Microsoft Graph sync with user or tenant consent depending on the selected surface.

Webhook details

Require Microsoft Graph subscription validation, renewal tracking, and tenant-scoped audit evidence.

Verification steps

Authorize a test tenant, confirm Graph consent scopes, run a sync-now check, and review admin health without exposing tenant ids.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.
Provider consent missing one of the required scopes: offline_access, User.Read, Mail.Read, Mail.Send, Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All, ChannelMessage.Send, ChatMessage.Send.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Microsoft 365 / Teams is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Teams channel message becomes task context while Outlook availability feeds the scheduler.

Meetings

Zoom

Meeting, webinar, recording, and event-subscription setup tracked through the connector hub.

Preview contract

Auth method: Zoom OAuth + signed event subscriptions
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview event subscription contract; recording sync stays gated until OAuth and webhook validation are configured.

Overview

Meeting, webinar, recording, and event-subscription setup tracked through the connector hub.

Prerequisites

Atlas owner/admin access
Zoom provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Zoom provider app in a sandbox workspace.
Configure the required deployment variables: ZOOM_CLIENT_ID, ZOOM_CLIENT_SECRET, ZOOM_WEBHOOK_SECRET.
Grant only these scopes during authorization: meeting:read, webinar:read, recording:read, user:read.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

ZOOM_CLIENT_ID
ZOOM_CLIENT_SECRET
ZOOM_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

meeting:read
webinar:read
recording:read
user:read

Mapping behavior

Map meeting ids, hosts, participants, webinars, recordings, transcripts, and event times into Atlas meeting records.

Sync direction

Inbound event and recording metadata sync after OAuth and webhook validation are both complete.

Webhook details

Validate signed event subscriptions, retry delivery logs, and recording availability without storing provider secrets.

Verification steps

Create a sandbox meeting, receive a signed event, and confirm the meeting timeline updates without raw payload leakage.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for ZOOM_CLIENT_ID, ZOOM_CLIENT_SECRET, ZOOM_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: meeting:read, webinar:read, recording:read, user:read.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Zoom is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Zoom meeting recording becomes a follow-up task pack once the connector passes webhook validation.

Work management

Jira

Issue, project, sprint, and status mapping setup for work intake and delivery evidence.

Preview contract

Auth method: Atlassian OAuth 2.0 + webhook secret
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview issue sync contract with explicit object mapping and webhook validation gates.

Overview

Issue, project, sprint, and status mapping setup for work intake and delivery evidence.

Prerequisites

Atlas owner/admin access
Jira provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Jira provider app in a sandbox workspace.
Configure the required deployment variables: JIRA_CLIENT_ID, JIRA_CLIENT_SECRET, JIRA_WEBHOOK_SECRET.
Grant only these scopes during authorization: read:jira-work, write:jira-work, read:jira-user, offline_access.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

JIRA_CLIENT_ID
JIRA_CLIENT_SECRET
JIRA_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

read:jira-work
write:jira-work
read:jira-user
offline_access

Mapping behavior

Map workspaces, teams, projects, issues, statuses, assignees, labels, milestones, and sprints into Atlas project intelligence.

Sync direction

Bi-directional only after mapping approval; preview mode remains inbound-first with explicit sync-now controls.

Webhook details

Validate provider webhooks, dedupe issue events, and keep external issue body text out of analytics payloads.

Verification steps

Connect a sandbox project, sync one issue, inspect mapping, and confirm retry logs show sanitized provider references.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for JIRA_CLIENT_ID, JIRA_CLIENT_SECRET, JIRA_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: read:jira-work, write:jira-work, read:jira-user, offline_access.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Jira is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Jira issue maps to an Atlas project task, then a status change refreshes the delivery dashboard.

Developer

GitLab

Group, project, merge request, issue, and pipeline evidence setup for engineering workflows.

Preview contract

Auth method: GitLab OAuth + signed project/group webhooks
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview developer evidence contract; inbound webhook processing remains gated by signed payload validation.

Overview

Group, project, merge request, issue, and pipeline evidence setup for engineering workflows.

Prerequisites

Atlas owner/admin access
GitLab provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the GitLab provider app in a sandbox workspace.
Configure the required deployment variables: GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET, GITLAB_WEBHOOK_SECRET.
Grant only these scopes during authorization: api, read_user, read_repository.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GITLAB_CLIENT_ID
GITLAB_CLIENT_SECRET
GITLAB_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

api
read_user
read_repository

Mapping behavior

Map organizations, repositories, projects, issues, merge requests, pull requests, branches, commits, pipelines, and installation owners to Atlas project evidence.

Sync direction

Mostly inbound evidence sync with outbound links, status references, and webhook-driven task updates.

Webhook details

Require provider signatures, installation or project scoping, retry logging, and idempotent event keys.

Verification steps

Connect a sandbox repository, open a test issue or merge request, and confirm Atlas records a normalized external reference only.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET, GITLAB_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: api, read_user, read_repository.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm GitLab is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A repository issue links to an Atlas task, then a merge request update refreshes project evidence without exposing raw webhook payloads.

Knowledge

Notion

Workspace pages, databases, owners, and knowledge references prepared for project context.

Preview contract

Auth method: Notion OAuth integration
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview knowledge sync contract; workspace content is not indexed until OAuth consent and mapping are verified.

Overview

Workspace pages, databases, owners, and knowledge references prepared for project context.

Prerequisites

Atlas owner/admin access
Notion provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Notion provider app in a sandbox workspace.
Configure the required deployment variables: NOTION_CLIENT_ID, NOTION_CLIENT_SECRET.
Grant only these scopes during authorization: read_content, update_content, read_user.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

NOTION_CLIENT_ID
NOTION_CLIENT_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

read_content
update_content
read_user

Mapping behavior

Map workspaces, spaces, pages, databases, owners, comments, and last-edited metadata into Atlas knowledge references.

Sync direction

Inbound knowledge indexing only after admin mapping approval and workspace consent.

Webhook details

Use provider event subscriptions where available; otherwise run bounded polling with retry and deletion awareness.

Verification steps

Connect a sandbox workspace, choose one space or database, run a dry sync, and confirm indexed records use stable external references.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for NOTION_CLIENT_ID, NOTION_CLIENT_SECRET.
Provider consent missing one of the required scopes: read_content, update_content, read_user.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Notion is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Confluence page or Notion database row becomes searchable project context after the admin approves space mapping.

Knowledge

Confluence

Space, page, comment, and knowledge-base mapping setup for project and customer evidence.

Preview contract

Auth method: Atlassian OAuth 2.0 + webhook secret
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Preview content sync contract with explicit space mapping and webhook validation gates.

Overview

Space, page, comment, and knowledge-base mapping setup for project and customer evidence.

Prerequisites

Atlas owner/admin access
Confluence provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Confluence provider app in a sandbox workspace.
Configure the required deployment variables: ATLASSIAN_CLIENT_ID, ATLASSIAN_CLIENT_SECRET, ATLASSIAN_WEBHOOK_SECRET.
Grant only these scopes during authorization: read:confluence-content.all, write:confluence-content, read:me.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

ATLASSIAN_CLIENT_ID
ATLASSIAN_CLIENT_SECRET
ATLASSIAN_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

read:confluence-content.all
write:confluence-content
read:me

Mapping behavior

Map workspaces, spaces, pages, databases, owners, comments, and last-edited metadata into Atlas knowledge references.

Sync direction

Inbound knowledge indexing only after admin mapping approval and workspace consent.

Webhook details

Use provider event subscriptions where available; otherwise run bounded polling with retry and deletion awareness.

Verification steps

Connect a sandbox workspace, choose one space or database, run a dry sync, and confirm indexed records use stable external references.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for ATLASSIAN_CLIENT_ID, ATLASSIAN_CLIENT_SECRET, ATLASSIAN_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: read:confluence-content.all, write:confluence-content, read:me.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Confluence is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Confluence page or Notion database row becomes searchable project context after the admin approves space mapping.

CRM

Salesforce

Connected-app, CRM object, account/contact/opportunity, sharing, and webhook proof gates for Growth Suite sync.

Adapter ready

Auth method: Salesforce OAuth connected app + event/webhook verification
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before CRM object sync, sharing, or live opportunity updates are claimed.

Overview

Connected-app, CRM object, account/contact/opportunity, sharing, and webhook proof gates for Growth Suite sync.

Prerequisites

Atlas owner/admin access
Salesforce provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Salesforce provider app in a sandbox workspace.
Configure the required deployment variables: SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, SALESFORCE_WEBHOOK_SECRET.
Grant only these scopes during authorization: api, refresh_token, offline_access, web.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

SALESFORCE_CLIENT_ID
SALESFORCE_CLIENT_SECRET
SALESFORCE_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

api
refresh_token
offline_access
web

Mapping behavior

Map accounts, contacts, companies, leads, opportunities, deal stages, owners, activities, and custom fields into Atlas Growth Suite records through approved field policies.

Sync direction

Sandbox/live provider proof gates control bi-directional sync; no CRM writeback starts until mapping, permissions, and rollback checks pass.

Webhook details

Validate object-change webhooks, dedupe event ids, preserve provider retry posture, and store only normalized CRM references in Atlas audit records.

Verification steps

Connect a sandbox CRM app, sync one account/contact/deal trio, validate field visibility policies, and confirm sanitized timeline evidence.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, SALESFORCE_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: api, refresh_token, offline_access, web.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Salesforce is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Salesforce opportunity or HubSpot deal opens an Atlas deal room, links approved customer context, and queues follow-up tasks.

CRM

HubSpot

HubSpot app scopes, CRM objects, deal pipeline, timeline, and webhook proof gates for Growth Suite sync.

Adapter ready

Auth method: HubSpot OAuth app + signed webhook validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before CRM object sync, workflow updates, or deal-room automation are claimed.

Overview

HubSpot app scopes, CRM objects, deal pipeline, timeline, and webhook proof gates for Growth Suite sync.

Prerequisites

Atlas owner/admin access
HubSpot provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the HubSpot provider app in a sandbox workspace.
Configure the required deployment variables: HUBSPOT_CLIENT_ID, HUBSPOT_CLIENT_SECRET, HUBSPOT_WEBHOOK_SECRET.
Grant only these scopes during authorization: crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

HUBSPOT_CLIENT_ID
HUBSPOT_CLIENT_SECRET
HUBSPOT_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

crm.objects.contacts.read
crm.objects.companies.read
crm.objects.deals.read

Mapping behavior

Map accounts, contacts, companies, leads, opportunities, deal stages, owners, activities, and custom fields into Atlas Growth Suite records through approved field policies.

Sync direction

Sandbox/live provider proof gates control bi-directional sync; no CRM writeback starts until mapping, permissions, and rollback checks pass.

Webhook details

Validate object-change webhooks, dedupe event ids, preserve provider retry posture, and store only normalized CRM references in Atlas audit records.

Verification steps

Connect a sandbox CRM app, sync one account/contact/deal trio, validate field visibility policies, and confirm sanitized timeline evidence.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for HUBSPOT_CLIENT_ID, HUBSPOT_CLIENT_SECRET, HUBSPOT_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm HubSpot is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Salesforce opportunity or HubSpot deal opens an Atlas deal room, links approved customer context, and queues follow-up tasks.

E-signature

DocuSign

DocuSign JWT/OAuth setup, envelope status, Connect callbacks, signing evidence, and audit proof gates.

Adapter ready

Auth method: DocuSign OAuth/JWT + Connect webhook validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before live envelope routing, signing, or certificate evidence is claimed.

Overview

DocuSign JWT/OAuth setup, envelope status, Connect callbacks, signing evidence, and audit proof gates.

Prerequisites

Atlas owner/admin access
DocuSign provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the DocuSign provider app in a sandbox workspace.
Configure the required deployment variables: DOCUSIGN_INTEGRATION_KEY, DOCUSIGN_USER_ID, DOCUSIGN_PRIVATE_KEY, DOCUSIGN_WEBHOOK_SECRET.
Grant only these scopes during authorization: signature, impersonation.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

DOCUSIGN_INTEGRATION_KEY
DOCUSIGN_USER_ID
DOCUSIGN_PRIVATE_KEY
DOCUSIGN_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

signature
impersonation

Mapping behavior

Map envelopes, recipients, templates, routing order, signing events, certificates, and audit packages into Atlas agreement evidence.

Sync direction

Provider-proof-gated send/status sync with sequential and parallel signing routes only after sandbox or live proof is retained.

Webhook details

Validate event signatures, callback ordering, signer-state transitions, idempotency keys, and certificate/audit package availability.

Verification steps

Run a sandbox envelope through send, view, sign, callback, completion, and disconnect checks while keeping signer tokens out of logs.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for DOCUSIGN_INTEGRATION_KEY, DOCUSIGN_USER_ID, DOCUSIGN_PRIVATE_KEY, DOCUSIGN_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: signature, impersonation.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm DocuSign is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A DocuSign, Adobe Acrobat Sign, Dropbox Sign, or PandaDoc envelope completes and Atlas attaches the certificate to the agreement timeline.

E-signature

Adobe Acrobat Sign

Adobe Acrobat Sign OAuth, agreement events, embedded signing, and webhook proof gates.

Adapter ready

Auth method: Adobe Acrobat Sign OAuth + webhook/event validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before live agreement send, embedded signing, or event evidence is claimed.

Overview

Adobe Acrobat Sign OAuth, agreement events, embedded signing, and webhook proof gates.

Prerequisites

Atlas owner/admin access
Adobe Acrobat Sign provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Adobe Acrobat Sign provider app in a sandbox workspace.
Configure the required deployment variables: ADOBE_ACROBAT_SIGN_CLIENT_ID, ADOBE_ACROBAT_SIGN_CLIENT_SECRET, ADOBE_ACROBAT_SIGN_WEBHOOK_SECRET.
Grant only these scopes during authorization: agreement_read, agreement_write, user_read.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

ADOBE_ACROBAT_SIGN_CLIENT_ID
ADOBE_ACROBAT_SIGN_CLIENT_SECRET
ADOBE_ACROBAT_SIGN_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

agreement_read
agreement_write
user_read

Mapping behavior

Map envelopes, recipients, templates, routing order, signing events, certificates, and audit packages into Atlas agreement evidence.

Sync direction

Provider-proof-gated send/status sync with sequential and parallel signing routes only after sandbox or live proof is retained.

Webhook details

Validate event signatures, callback ordering, signer-state transitions, idempotency keys, and certificate/audit package availability.

Verification steps

Run a sandbox envelope through send, view, sign, callback, completion, and disconnect checks while keeping signer tokens out of logs.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for ADOBE_ACROBAT_SIGN_CLIENT_ID, ADOBE_ACROBAT_SIGN_CLIENT_SECRET, ADOBE_ACROBAT_SIGN_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: agreement_read, agreement_write, user_read.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Adobe Acrobat Sign is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A DocuSign, Adobe Acrobat Sign, Dropbox Sign, or PandaDoc envelope completes and Atlas attaches the certificate to the agreement timeline.

E-signature

Dropbox Sign

Dropbox Sign embedded signing, callback sequencing, signature requests, and audit proof gates.

Adapter ready

Auth method: Dropbox Sign API key or OAuth + callback validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before live signature requests, callback ordering, or audit packages are claimed.

Overview

Dropbox Sign embedded signing, callback sequencing, signature requests, and audit proof gates.

Prerequisites

Atlas owner/admin access
Dropbox Sign provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Dropbox Sign provider app in a sandbox workspace.
Configure the required deployment variables: DROPBOX_SIGN_CLIENT_ID, DROPBOX_SIGN_API_KEY, DROPBOX_SIGN_WEBHOOK_SECRET.
Grant only these scopes during authorization: signature_request, account, template.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

DROPBOX_SIGN_CLIENT_ID
DROPBOX_SIGN_API_KEY
DROPBOX_SIGN_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

signature_request
account
template

Mapping behavior

Map envelopes, recipients, templates, routing order, signing events, certificates, and audit packages into Atlas agreement evidence.

Sync direction

Provider-proof-gated send/status sync with sequential and parallel signing routes only after sandbox or live proof is retained.

Webhook details

Validate event signatures, callback ordering, signer-state transitions, idempotency keys, and certificate/audit package availability.

Verification steps

Run a sandbox envelope through send, view, sign, callback, completion, and disconnect checks while keeping signer tokens out of logs.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for DROPBOX_SIGN_CLIENT_ID, DROPBOX_SIGN_API_KEY, DROPBOX_SIGN_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: signature_request, account, template.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Dropbox Sign is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A DocuSign, Adobe Acrobat Sign, Dropbox Sign, or PandaDoc envelope completes and Atlas attaches the certificate to the agreement timeline.

E-signature

PandaDoc

PandaDoc document send, embedded signing session, template, and webhook proof gates.

Adapter ready

Auth method: PandaDoc OAuth/API key + webhook validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before live document send, embedded signing, or template sync is claimed.

Overview

PandaDoc document send, embedded signing session, template, and webhook proof gates.

Prerequisites

Atlas owner/admin access
PandaDoc provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the PandaDoc provider app in a sandbox workspace.
Configure the required deployment variables: PANDADOC_CLIENT_ID, PANDADOC_API_KEY, PANDADOC_WEBHOOK_SECRET.
Grant only these scopes during authorization: documents:read, documents:write, templates:read.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

PANDADOC_CLIENT_ID
PANDADOC_API_KEY
PANDADOC_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

documents:read
documents:write
templates:read

Mapping behavior

Map envelopes, recipients, templates, routing order, signing events, certificates, and audit packages into Atlas agreement evidence.

Sync direction

Provider-proof-gated send/status sync with sequential and parallel signing routes only after sandbox or live proof is retained.

Webhook details

Validate event signatures, callback ordering, signer-state transitions, idempotency keys, and certificate/audit package availability.

Verification steps

Run a sandbox envelope through send, view, sign, callback, completion, and disconnect checks while keeping signer tokens out of logs.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for PANDADOC_CLIENT_ID, PANDADOC_API_KEY, PANDADOC_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: documents:read, documents:write, templates:read.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm PandaDoc is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A DocuSign, Adobe Acrobat Sign, Dropbox Sign, or PandaDoc envelope completes and Atlas attaches the certificate to the agreement timeline.

AI Providers

Provider mode, BYOK key posture, fallback chain, model catalog, cost, and latency tracking.

Adapter ready

Auth method: BYOK secret reference or Atlas cloud mode
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Runtime routing through provider selection and fallback policy.

Overview

Provider mode, BYOK key posture, fallback chain, model catalog, cost, and latency tracking.

Prerequisites

Atlas owner/admin access
A deployment-managed API key for one supported provider or an approved tenant BYOK vault path
A sandbox/test model policy for first credentialed proof, with live execution explicitly opt-in only
A private proof-store location and proof HMAC secret before provider sandbox/live captures are retained

Setup steps

Open Settings -> AI Providers and choose the tenant provider mode, default model, and fallback order.
Configure at least one concrete provider credential path: OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, Azure OpenAI API key plus endpoint, local loopback OLLAMA_BASE_URL, or encrypted BYOK vault keys.
Set AI_PROVIDER_KEY_ENCRYPTION_SECRET before saving tenant BYOK keys, and keep provider API keys in environment or the Atlas provider vault rather than browser-visible setup notes.
Run the no-key readiness summary first; keep user-facing AI features setup-required, disabled, unavailable, or Coming Soon until credential, transport, catalog, proof, replay, and product-activation gates pass.
Retain credentialed replay proof for every routed AI surface before claiming sandbox or live provider execution.

Configuration fields

OPENAI_API_KEY
ANTHROPIC_API_KEY
GEMINI_API_KEY
AZURE_OPENAI_API_KEY
AZURE_OPENAI_ENDPOINT
AZURE_OPENAI_API_VERSION
OLLAMA_BASE_URL
AI_PROVIDER_KEY_ENCRYPTION_SECRET
ATLAS_AI_PROVIDER_PROOF_FILE
ATLAS_AI_PROVIDER_PROOF_HMAC_SECRET
Provider routing mode, fallback order, usage ledger retention, and credentialed replay proof

Required permissions/scopes

model inference
usage telemetry
fallback routing

Mapping behavior

Map providers, models, capability flags, routing policies, fallback order, usage, latency, and cost envelopes into Atlas AI governance.

Sync direction

Runtime call routing only; provider secrets remain in environment or vault references and are never mirrored to the browser.

Webhook details

AI providers are request/response integrations; usage events and failures are traced through Atlas telemetry instead of webhooks.

Verification steps

Configure a sandbox key, run a provider-readiness check, verify fallback behavior, and confirm cost/latency metrics emit.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

No concrete provider credential path is configured for OpenAI, Anthropic, Gemini, Azure OpenAI, local Ollama, or encrypted BYOK.
AI_PROVIDER_KEY_ENCRYPTION_SECRET is missing or invalid, so tenant BYOK keys cannot be stored or retrieved safely.
Azure OpenAI is partially configured; both AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT are required before that provider can execute.
OLLAMA_BASE_URL is not a bare loopback origin, so local provider execution is blocked.
Provider proof, replay proof, fallback routing, default-model validity, or product-surface activation remains gated.

Troubleshooting

Use Settings -> AI Providers to inspect safe readiness, activation matrix, default model, fallback chain, and usage/cost posture.
Confirm at least one concrete provider env var or encrypted BYOK credential is present; generic aggregate credential placeholders are not supported runtime inputs.
For Gemini, configure GEMINI_API_KEY; GOOGLE_API_KEY is not accepted by the Atlas runtime contract.
For Azure OpenAI, verify the endpoint is the deployment resource origin and keep AZURE_OPENAI_API_VERSION on the deployment-approved version.
For local Ollama, use only a loopback origin such as http://localhost:11434 with no path, credentials, query, or fragment.
Re-run safe readiness after credential rotation and verify telemetry remains aggregate-only without key prefixes, provider payloads, prompts, outputs, endpoints, provider names, model slugs, or proof paths.

Rollback / disconnect steps

Disable or clear the affected provider in Settings -> AI Providers.
Remove or rotate the provider API key, Azure endpoint credential, Ollama endpoint, or tenant BYOK vault entry from the environment or vault.
Clear default-model and fallback-chain entries that target the removed provider.
Re-run safe readiness and confirm product AI surfaces return setup-required, disabled, unavailable, or Coming Soon states until replacement proof is retained.
Retain an audit note with aggregate provider mode, readiness status, and usage-window counts only.

Admin notes

Keep provider API keys server-side in deployment env or encrypted Atlas vault storage; never paste keys into tickets, tasks, comments, prompts, or docs.
Treat no-key fixture proof as schema and release evidence only; sandbox/live proof is required before claiming credentialed model execution.
Document provider mode, default model, fallback order, proof owner, cost budget, and rotation owner in your internal AI runbook.
Review aggregate usage, latency, cost, fallback, and zero-token counts after every provider change without exposing provider names, model slugs, prompts, outputs, key prefixes, endpoints, or proof paths.

End-user notes

Users should see unavailable, Coming Soon, setup-required, or disabled states until AI provider readiness is executable.
Users should not paste provider credentials, key prefixes, prompts, model outputs, proof paths, local endpoints, or provider payloads into notes, tasks, comments, or support requests.
Tenant provider mode, fallback policy, and proof gates are admin-owned controls; personal OAuth grants do not apply to AI provider execution.

Testing checklist

No-key readiness shows setup-required, disabled, unavailable, or Coming Soon states without claiming live model execution.
At least one concrete provider credential path validates without exposing keys, key prefixes, provider names, model slugs, prompts, outputs, endpoints, payloads, or proof paths.
Default model and fallback-chain entries reference active catalog rows for the selected provider mode.
Credentialed replay proof covers every routed product AI surface before sandbox or live provider activation is claimed.
Usage, cost, latency, fallback, and zero-token readbacks remain aggregate-only after a provider change.

Example workflows

Atlas tries the primary model, falls back on a configured provider, and records cost and latency without exposing API keys.

Identity

SSO and SCIM

Enterprise SAML login, SCIM provisioning, deprovisioning, and audit evidence.

Setup required

Auth method: SAML 2.0 + SCIM bearer token
Manage path: Open setup surface
Runtime identity setup and SCIM health/activity live in Settings -> Security.
Sync model: Admin-owned identity sync with audit trails.

Overview

Enterprise SAML login, SCIM provisioning, deprovisioning, and audit evidence.

Prerequisites

Atlas owner/admin access
Identity provider admin access for SAML and SCIM provisioning
A break-glass Atlas owner who can sign in without SSO
A sandbox user or pilot group for first provisioning validation

Setup steps

Open Settings -> Security and copy the Atlas ACS URL, metadata URL, and SCIM base URL.
Choose the Okta, Microsoft Entra, Google Workspace, or generic setup guide that matches your identity provider.
Configure SAML in the provider, then paste IdP metadata XML into Atlas or enter Entity ID, SSO URL, and x509 certificate manually.
Create a SCIM token in Atlas, copy the one-time bearer token into the provider, and map userName, name, externalId, and active.
Run the provider test connection or pilot user provisioning cycle, then confirm Atlas SCIM health moves to active and the activity panel shows accepted create/update/disable counts.
Paste a small JSON export from the provider provisioning logs into Provider log review to inspect aggregate failure and unknown-operation buckets.

Configuration fields

IdP Entity ID, SSO URL, x509 certificate, optional SP private key
Atlas ACS URL and metadata URL copied into the provider
SCIM base URL, one-time bearer token, token rotation owner, and pilot user group
Attribute mapping for userName, name.givenName, name.familyName, externalId, and active
Optional JSON provider-log export for transient preview of operation and failure buckets

Required permissions/scopes

identity
groups
users
provisioning

Mapping behavior

Map SAML Entity IDs, ACS/metadata URLs, SCIM userName, name, externalId, active state, provisioning health, group readiness, accepted activity, provider-log preview, and deprovisioning actions into enterprise admin governance.

Sync direction

Inbound identity sync with admin-owned provisioning and Atlas SCIM responses; aggregate health/activity/group readiness is read from Atlas tokens, memberships, SCIM Group rows, group-member links, and accepted audit-event state.

Webhook details

Require signed SAML assertions where enabled, SCIM bearer-token rotation, audit logging, and provider-side provisioning-log review before claiming live parity.

Verification steps

Run SAML metadata validation, provision a sandbox user through SCIM, disable the user, confirm Atlas SCIM health/activity shows a recent accepted request, confirm /Groups protocol and mapped-group posture, and preview exported provider log plus Group Push rows.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

SAML Entity ID, SSO URL, certificate, signing, or encryption settings do not match between Atlas and the provider.
SCIM token was copied incorrectly, revoked, or issued for a different environment.
Provider attribute mapping omits userName, externalId, or active state, so Atlas cannot match memberships reliably.
Atlas SCIM health/activity is awaiting first sync or stale because no successful provider request has arrived recently.
Provider log review reports attention required because exported rows contain failed events or unrecognized operation names.

Troubleshooting

Use the provider-specific guide in Settings -> Security to compare SAML endpoints, SCIM base URL, and attribute mapping.
Run the SAML sample-response test with non-production data before enabling broad enforcement.
Rotate the SCIM token if it may have been exposed; Atlas never shows plaintext tokens after creation.
Confirm group readiness still marks /Groups unsupported until group protocol parity is intentionally enabled.
Group readiness as an Atlas-side rollout checklist only remains separate from provider certification.
Use Group readiness and Group Push preview as Atlas-side rollout checklists only; they are not provider certification, nested group support, or exact directory membership parity.
Use Provider log review for transient exported-row normalization; Atlas health remains aggregate-only and durable provider-log ingestion is still proof-gated.

Rollback / disconnect steps

Disable provider provisioning before revoking the Atlas SCIM token.
Revoke the SCIM token in Settings -> Security and confirm health no longer reports active token posture.
Disable SSO only after confirming break-glass owner access still works.
Export audit logs for the change window when enterprise evidence is required.

Admin notes

Start with one pilot group and verify create, update, deactivate, and login behavior before broad enforcement.
Keep provider-side provisioning logs in the IdP console; Atlas currently displays aggregate health/activity, not provider log payloads.
Provider log preview is no-retention troubleshooting and should not be treated as live provider API ingestion proof.
Do not paste SAML XML, x509 material, assertion fields, SCIM external ids, token names, prefixes, group names, group ids, member edges, provider messages, correlation ids, or exact health/provider-log timestamps into support notes.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

An Okta, Microsoft Entra, Google Workspace, or generic IdP setup provisions Atlas members, then a deprovision event disables access and updates aggregate SCIM health/activity.

Platform

Webhooks and API

Outbound events, HMAC signatures, retries, delivery logs, and scoped API tokens.

Live

Auth method: PAT + per-subscription HMAC-signed delivery
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Event delivery with retry and per-subscription signed payload verification.

Overview

Outbound events, HMAC signatures, retries, delivery logs, and scoped API tokens.

Prerequisites

Atlas owner/admin access
Access to the receiver endpoint and its deployment logs
Sandbox or test receiver URL for first validation

Setup steps

Open Settings -> Webhooks and create an outbound subscription from the Atlas manage surface.
Choose the allowed event types, enter the receiver endpoint, and store the one-time generated signing secret in the receiver.
Validate HMAC signature, timestamp tolerance, and quick 2xx acknowledgement with a test delivery.
Return to Settings -> Integrations to review summary-only receipt readback, retries, and rollback state.

Configuration fields

Subscription name and allowed event types
Receiver endpoint URL entered in Settings -> Webhooks
One-time generated per-subscription signing secret
Retry policy, replay workflow, owner approval, and rollback notes

Required permissions/scopes

events:read
webhooks:write
tokens:manage

Mapping behavior

Map API tokens, webhook subscriptions, event types, delivery attempts, signatures, and retry states to Atlas platform governance.

Sync direction

Outbound event delivery with inbound API access through scoped tokens.

Webhook details

Require HMAC signatures, timestamp tolerance, retry policy, delivery logs, and explicit secret rotation.

Verification steps

Create a sandbox webhook, send a test event, validate signature handling, and verify failed delivery retries.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

No active webhook subscription or scoped API token has been created from the manage surface.
Receiver signature validation fails because the per-subscription secret or timestamp tolerance is incorrect.
Receiver returns a non-2xx response, times out, or exhausts retry attempts.
Delivery logs are present, but receipt readback remains summary-only and does not expose URLs, payloads, response bodies, or delivery ids.

Troubleshooting

Open Settings -> Webhooks to inspect delivery status, retry timing, and replay controls for the affected subscription.
Confirm the receiver responds with a quick 2xx before running expensive downstream work.
Rotate the per-subscription signing secret if it may have been exposed, then update the receiver before testing again.
Use Settings -> Integrations only for aggregate receipt posture; use the webhook manage surface for detailed admin-only diagnostics.

Rollback / disconnect steps

Disable the subscription in Settings -> Webhooks.
Rotate or delete the per-subscription signing secret if it may have been exposed.
Replay or clear pending deliveries from the webhook manage surface after the receiver is healthy.
Run a final receipt-readback check from Settings -> Integrations.

Admin notes

Use least-privilege event allowlists and test receivers before live enablement.
Document receiver ownership, escalation path, signing-secret rotation, and retry policy in your internal runbook.
Review webhook delivery logs after every receiver deployment, event mapping change, or secret rotation.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

Atlas sends a signed task.updated webhook to a customer endpoint and records delivery attempts for audit review.

Storage

Dropbox

Dropbox OAuth, folder mapping, artifact storage, webhook, and permission proof setup.

Setup required

Auth method: Dropbox OAuth + webhook signature verification
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Credential-gated storage metadata sync after folder mapping and permission proof.

Overview

Dropbox OAuth, folder mapping, artifact storage, webhook, and permission proof setup.

Prerequisites

Atlas owner/admin access
Dropbox provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Dropbox provider app in a sandbox workspace.
Configure the required deployment variables: DROPBOX_CLIENT_ID, DROPBOX_CLIENT_SECRET, DROPBOX_WEBHOOK_SECRET.
Grant only these scopes during authorization: files.metadata.read, files.content.read, sharing.read.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

DROPBOX_CLIENT_ID
DROPBOX_CLIENT_SECRET
DROPBOX_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

files.metadata.read
files.content.read
sharing.read

Mapping behavior

Map providers, folders, files, permissions, owners, hashes, and retention tags into Atlas document and evidence references.

Sync direction

Credential-gated metadata sync with content access disabled until folder mapping and permission proof are retained.

Webhook details

Validate provider event signatures or Graph subscriptions, renewal timing, delete events, and retry logs before enabling background updates.

Verification steps

Connect a sandbox folder, sync one metadata row, verify permission boundaries, then disconnect and confirm watches are stopped.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for DROPBOX_CLIENT_ID, DROPBOX_CLIENT_SECRET, DROPBOX_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: files.metadata.read, files.content.read, sharing.read.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Dropbox is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A signed contract stored in Dropbox, Box, or OneDrive appears as an Atlas evidence reference without exposing the provider file URL.

Storage

Box

Box OAuth, enterprise app authorization, folder mapping, and webhook proof setup.

Setup required

Auth method: Box OAuth or JWT app + webhook validation
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Credential-gated storage metadata sync after enterprise authorization and folder mapping.

Overview

Box OAuth, enterprise app authorization, folder mapping, and webhook proof setup.

Prerequisites

Atlas owner/admin access
Box provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Box provider app in a sandbox workspace.
Configure the required deployment variables: BOX_CLIENT_ID, BOX_CLIENT_SECRET, BOX_WEBHOOK_SECRET.
Grant only these scopes during authorization: root_readwrite, manage_webhook.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

BOX_CLIENT_ID
BOX_CLIENT_SECRET
BOX_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

root_readwrite
manage_webhook

Mapping behavior

Map providers, folders, files, permissions, owners, hashes, and retention tags into Atlas document and evidence references.

Sync direction

Credential-gated metadata sync with content access disabled until folder mapping and permission proof are retained.

Webhook details

Validate provider event signatures or Graph subscriptions, renewal timing, delete events, and retry logs before enabling background updates.

Verification steps

Connect a sandbox folder, sync one metadata row, verify permission boundaries, then disconnect and confirm watches are stopped.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for BOX_CLIENT_ID, BOX_CLIENT_SECRET, BOX_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: root_readwrite, manage_webhook.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Box is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A signed contract stored in Dropbox, Box, or OneDrive appears as an Atlas evidence reference without exposing the provider file URL.

Storage

OneDrive

OneDrive and SharePoint file metadata, permission mapping, and Microsoft Graph change notification setup.

Setup required

Auth method: Microsoft Graph OAuth + change notifications
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Credential-gated Microsoft storage sync after admin consent, mapping, and subscription proof.

Overview

OneDrive and SharePoint file metadata, permission mapping, and Microsoft Graph change notification setup.

Prerequisites

Atlas owner/admin access
OneDrive provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the OneDrive provider app in a sandbox workspace.
Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.
Grant only these scopes during authorization: Files.Read.All, Sites.Read.All, offline_access.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

MICROSOFT_OAUTH_CLIENT_ID
MICROSOFT_OAUTH_CLIENT_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

Files.Read.All
Sites.Read.All
offline_access

Mapping behavior

Map providers, folders, files, permissions, owners, hashes, and retention tags into Atlas document and evidence references.

Sync direction

Credential-gated metadata sync with content access disabled until folder mapping and permission proof are retained.

Webhook details

Validate provider event signatures or Graph subscriptions, renewal timing, delete events, and retry logs before enabling background updates.

Verification steps

Connect a sandbox folder, sync one metadata row, verify permission boundaries, then disconnect and confirm watches are stopped.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.
Provider consent missing one of the required scopes: Files.Read.All, Sites.Read.All, offline_access.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm OneDrive is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A signed contract stored in Dropbox, Box, or OneDrive appears as an Atlas evidence reference without exposing the provider file URL.

Billing

Stripe

Stripe customer, subscription, invoice, charge, event destination, signature, and replay setup.

Setup required

Auth method: Stripe restricted key + signed webhooks
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Credential-gated billing event sync after webhook signing, replay, and sandbox proof.

Overview

Stripe customer, subscription, invoice, charge, event destination, signature, and replay setup.

Prerequisites

Atlas owner/admin access
Stripe provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Stripe provider app in a sandbox workspace.
Configure the required deployment variables: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET.
Grant only these scopes during authorization: customers, subscriptions, invoices, webhooks.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

STRIPE_SECRET_KEY
STRIPE_WEBHOOK_SECRET
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

customers
subscriptions
invoices
webhooks

Mapping behavior

Map customers, subscriptions, invoices, charges, payment status, billing contacts, and event ids into account-health evidence.

Sync direction

Inbound billing-event sync with optional account-health updates after sandbox webhook replay and reconciliation proof pass.

Webhook details

Require Stripe signature verification, event idempotency, retry awareness, out-of-order event handling, and manual replay guidance.

Verification steps

Run Stripe sandbox events through signature validation, failed-delivery retry, manual replay, and account-health reconciliation.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET.
Provider consent missing one of the required scopes: customers, subscriptions, invoices, webhooks.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Stripe is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Stripe subscription event updates customer health and queues renewal follow-up while Atlas records only aggregate billing posture.

Growth Suite

Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign

Provider admission, sandbox/live proof boundaries, signing, CRM, PDF, and audit readiness.

Adapter ready

Auth method: Provider OAuth or credentialed sandbox/live runner
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Provider proof gates before external parity is claimed.

Overview

Provider admission, sandbox/live proof boundaries, signing, CRM, PDF, and audit readiness.

Prerequisites

Atlas owner/admin access
Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Create or select the Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign provider app in a sandbox workspace.
Configure the required deployment variables: GROWTH_SUITE_*, DOCUSIGN_*, ADOBE_*, DROPBOX_SIGN_*, PANDADOC_*.
Grant only these scopes during authorization: crm objects, signing envelopes, PDF services, webhooks.
Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

Configuration fields

GROWTH_SUITE_*
DOCUSIGN_*
ADOBE_*
DROPBOX_SIGN_*
PANDADOC_*
OAuth redirect URI or provider callback URL
Webhook signing secret or provider event secret when the connector supports events
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

crm objects
signing envelopes
PDF services
webhooks

Mapping behavior

Map CRM records, signing envelopes, PDF assets, templates, audit artifacts, and provider proof records into the Growth Suite evidence model.

Sync direction

Provider-specific OAuth or credentialed runner sync only after sandbox or live proof gates pass.

Webhook details

Validate CRM object webhooks, signing callbacks, PDF lifecycle events, and provider audit callback authenticity.

Verification steps

Run provider admission, load sandbox proof, execute one CRM/signing/PDF fixture, and review evidence export readiness.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

Missing or mistyped deployment variables for GROWTH_SUITE_*, DOCUSIGN_*, ADOBE_*, DROPBOX_SIGN_*, PANDADOC_*.
Provider consent missing one of the required scopes: crm objects, signing envelopes, PDF services, webhooks.
Webhook signature, OAuth state, redirect URI, or callback validation fails.
Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

Troubleshooting

Confirm Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign is configured in the correct provider workspace or tenant.
Re-run the connector validation check from Settings -> Integrations after changing credentials.
Inspect sync logs for retryable provider errors, disabled connections, and sanitized callback failures.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect the app.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A HubSpot opportunity triggers an Atlas deal room, sends a DocuSign envelope, and attaches PDF audit evidence.

Business ops

Dropbox, Box, OneDrive, Stripe

Storage and billing connectors are tracked in the setup backlog with credential gates.

Setup required

Auth method: OAuth or provider secret
Manage path: Open setup surface
Runtime status remains in Settings -> Integrations.
Sync model: Credential-gated setup path; no background sync starts without explicit connection.

Overview

Storage and billing connectors are tracked in the setup backlog with credential gates.

Prerequisites

Atlas owner/admin access
Dropbox, Box, OneDrive, Stripe provider admin or approved user access
Sandbox workspace or tenant for first validation

Setup steps

Choose one provider-specific setup group: Dropbox, Box, OneDrive, Stripe.
Configure every deployment variable for the chosen provider group before enabling any connection attempt.
Grant only the scopes needed by that provider path: files, billing, webhooks.
Open Settings -> Integrations to confirm the aggregate card remains execution-gated until provider-specific OAuth, sync, webhook, and sandbox/live proof pass.

Configuration fields

Dropbox: DROPBOX_CLIENT_ID, DROPBOX_CLIENT_SECRET, DROPBOX_WEBHOOK_SECRET
Box: BOX_CLIENT_ID, BOX_CLIENT_SECRET, BOX_WEBHOOK_SECRET
OneDrive: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET
Stripe: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
Provider-specific OAuth redirect URI or callback URL
Provider webhook signing secret, event destination, or Graph subscription evidence
Sandbox/live mode, tenant scope, owner approval, and field mapping profile

Required permissions/scopes

files
billing
webhooks

Mapping behavior

Map storage accounts, folders, files, billing customers, subscriptions, charges, invoices, and webhook events into operational records.

Sync direction

Credential-gated sync with provider-specific object mapping and billing/storage separation.

Webhook details

Require provider signatures, file permission checks, billing webhook idempotency, and sandbox mode before live enablement.

Verification steps

Connect a sandbox provider, sync one file or billing event, validate object mapping, and disconnect cleanly.
Confirm analytics and logs show only sanitized route, status, and action metadata.

Common failure modes

No complete provider setup group is configured. Available groups: Dropbox, Box, OneDrive, Stripe.
Only a partial provider family prefix is present, so Atlas blocks execution instead of claiming aggregate readiness.
Provider consent missing one of the required scopes: files, billing, webhooks.
Provider-specific OAuth, webhook, sandbox/live proof, or callback validation has not been retained yet.

Troubleshooting

Confirm exactly which provider group is being enabled before rotating or adding deployment variables.
Re-run the connector validation check from Settings -> Integrations after completing the chosen group.
Inspect sync logs for provider-scoped errors; the aggregate card should remain proof-gated until live evidence is retained.
Rotate provider credentials if a secret may have been exposed, then disconnect and reconnect only the affected provider path.

Rollback / disconnect steps

Disable the connector in Settings -> Integrations.
Revoke the provider app or OAuth grant in the provider admin console.
Rotate any webhook signing secret, API token, or BYOK key that was used during setup.
Run a final health check and verify no retry queue remains active.

Admin notes

Use least-privilege scopes and sandbox proof before live enablement.
Document object mappings, owner approvals, and provider app ids in your internal runbook.
Review audit logs after every credential rotation, mapping change, or provider app permission update.

End-user notes

Users should see unavailable, coming-soon, setup-required, or disabled states until the provider is authorized.
Users should not paste provider credentials into notes, tasks, comments, or support requests.
Disconnecting a personal OAuth grant should leave shared tenant connectors intact.

Testing checklist

Sandbox authorization succeeds.
Scope review matches this page.
Webhook or callback validation succeeds where supported.
Sync-now or dry-run proof records sanitized evidence.
Disconnect, retry, and rollback paths work.

Example workflows

A Stripe subscription event updates account health while a connected storage folder keeps signed artifacts available.