Atlas integrations setup

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

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

1. 1

   Create or select the Slack provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: SLACK_CLIENT_ID, SLACK_CLIENT_SECRET, SLACK_SIGNING_SECRET, SLACK_TOKEN_SECRET.

3. 3

   Grant only these scopes during authorization: commands, chat:write, channels:read, users:read.email.

4. 4

   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.

5. 5

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the GitHub App provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, GITHUB_APP_WEBHOOK_SECRET, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_SECRET.

3. 3

   Grant only these scopes during authorization: issues, pull_requests, metadata, webhooks.

4. 4

   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.

5. 5

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• issues
• pull_requests
• metadata
• webhooks

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Gmail provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, GMAIL_REDIRECT_URI, GMAIL_TOKEN_SECRET, GMAIL_PUBSUB_TOPIC_NAME.

3. 3

   Grant only these scopes during authorization: openid, email, profile, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/gmail.modify.

4. 4

   Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.

5. 5

   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.

6. 6

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Google Calendar provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.

3. 3

   Grant only these scopes during authorization: calendar.readonly, openid, email, profile.

4. 4

   Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.

5. 5

   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.

6. 6

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• calendar.readonly
• openid
• email
• profile

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Google Workspace provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GOOGLE_WORKSPACE_CLIENT_ID, GOOGLE_WORKSPACE_CLIENT_SECRET, GOOGLE_WORKSPACE_WEBHOOK_SECRET.

3. 3

   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.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• 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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

Outlook calendar reads through Microsoft Graph for planning and availability.

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

1. 1

   Create or select the Microsoft Calendar provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET, CALENDAR_TOKEN_SECRET.

3. 3

   Grant only these scopes during authorization: User.Read, Calendars.Read, offline_access.

4. 4

   Return to Settings -> Integrations to review local OAuth credential freshness, refresh-due counts, disabled rows, and reconnect posture without upstream provider calls.

5. 5

   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.

6. 6

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• User.Read
• Calendars.Read
• offline_access

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Linear provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: LINEAR_CLIENT_ID, LINEAR_CLIENT_SECRET.

3. 3

   Grant only these scopes during authorization: read, write.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• read
• write

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Microsoft 365 / Teams provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.

3. 3

   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.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Zoom provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: ZOOM_CLIENT_ID, ZOOM_CLIENT_SECRET, ZOOM_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: meeting:read, webinar:read, recording:read, user:read.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

Meeting notes, summaries, and transcripts imported from Granola against the engagement they belong to.

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

1. 1

   Create or select the Granola provider app in a sandbox workspace.

2. 2

   Create the connector from the manage surface; signing secrets are generated per subscription or connection.

3. 3

   Grant only these scopes during authorization: personal, public.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• No deployment-wide secret required; per-subscription signing secrets are generated in Atlas
• 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

• personal
• public

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

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

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

• 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.

• Generated signing secret, subscription state, or scoped token was not created from the manage surface.
• Provider consent missing one of the required scopes: personal, public.
• Webhook signature, OAuth state, redirect URI, or callback validation fails.
• Provider rate limits, disabled provider app, revoked consent, or sandbox/live mode mismatch.

• Confirm Granola 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Jira provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: JIRA_CLIENT_ID, JIRA_CLIENT_SECRET, JIRA_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: read:jira-work, write:jira-work, read:jira-user, offline_access.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the GitLab provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET, GITLAB_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: api, read_user, read_repository.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• api
• read_user
• read_repository

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Notion provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: NOTION_CLIENT_ID, NOTION_CLIENT_SECRET.

3. 3

   Grant only these scopes during authorization: read_content, update_content, read_user.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• read_content
• update_content
• read_user

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Confluence provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: ATLASSIAN_CLIENT_ID, ATLASSIAN_CLIENT_SECRET, ATLASSIAN_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: read:confluence-content.all, write:confluence-content, read:me.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Salesforce provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, SALESFORCE_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: api, refresh_token, offline_access, web.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• api
• refresh_token
• offline_access
• web

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the HubSpot provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: HUBSPOT_CLIENT_ID, HUBSPOT_CLIENT_SECRET, HUBSPOT_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the DocuSign provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: DOCUSIGN_INTEGRATION_KEY, DOCUSIGN_USER_ID, DOCUSIGN_PRIVATE_KEY, DOCUSIGN_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: signature, impersonation.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• signature
• impersonation

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Adobe Acrobat Sign provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: ADOBE_ACROBAT_SIGN_CLIENT_ID, ADOBE_ACROBAT_SIGN_CLIENT_SECRET, ADOBE_ACROBAT_SIGN_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: agreement_read, agreement_write, user_read.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• agreement_read
• agreement_write
• user_read

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Dropbox Sign provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: DROPBOX_SIGN_CLIENT_ID, DROPBOX_SIGN_API_KEY, DROPBOX_SIGN_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: signature_request, account, template.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• signature_request
• account
• template

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the PandaDoc provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: PANDADOC_CLIENT_ID, PANDADOC_API_KEY, PANDADOC_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: documents:read, documents:write, templates:read.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• documents:read
• documents:write
• templates:read

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

• Workspace owner or administrator access
• For your own key: an API key from Anthropic, OpenAI, Google Gemini, or Azure OpenAI, with access to the models you plan to use
• For a local runtime: a model server that Atlas can reach at a local address

1. 1

   Open Settings, then AI Providers. Only workspace owners and administrators can change these settings.

2. 2

   Choose how Atlas runs AI features for the workspace: the Atlas managed default, your own key for Anthropic, OpenAI, Google Gemini, or Azure OpenAI, or a model runtime on your own network.

3. 3

   To use your own key, paste it into the key field and save. Atlas checks the key with the provider before it saves it, and refuses a key the provider rejects. Atlas stores the key encrypted and afterwards shows only its first four characters.

4. 4

   Decide what happens when your key cannot be used, for example because it was revoked at the provider. Turn on Use the Atlas default when your key cannot be used to keep AI features running on the Atlas default. Leave it off to stop AI features with an error until an administrator updates the key. The status line at the top of the page shows the active mode and whether this fallback is on.

5. 5

   Choose the default model and, if you want one, the order in which other models are tried when the first is unavailable.

6. 6

   Run an AI feature, such as a meeting summary, and confirm that the usage panel records the call.

• Mode: the Atlas managed default, your own key, or a local runtime
• API key, checked with the provider when you save it, stored encrypted and shown as its first four characters
• Use the Atlas default when your key cannot be used, for your own key only
• Azure OpenAI endpoint, for Azure OpenAI only
• Local runtime address, for a local runtime only
• Default model
• Fallback order

• model inference
• usage telemetry
• fallback routing

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

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

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

• 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.

• The provider rejected the key when you saved it. Atlas does not save a key the provider refuses; check that the key is correct and active, then paste it again.
• Atlas could not reach the provider to check the key, so the key was not saved. Try again in a moment.
• The provider rejected the key after it was saved, for example because it was revoked. AI features return an error until an administrator replaces the key, unless Use the Atlas default when your key cannot be used is on.
• The key belongs to a different provider from the one the mode names, so the provider refuses it.
• A model runtime on your own network cannot be reached from Atlas, or its address is not a local one.
• The workspace has reached its AI usage limit for the current period.

• Open Settings, then AI Providers, and check the active mode, whether fallback to the Atlas default is on, the key prefix, the default model, and the fallback order.
• If you rotated the key at your provider, paste the new key and save. The old key stops working at once.
• For Azure OpenAI, use the endpoint of your own deployment resource.
• After any change, check the usage panel for failed calls.

• Open Settings, then AI Providers, and choose Reset to cloud. Atlas removes your key and returns the workspace to the Atlas managed default.
• Revoke the key at your provider as well, so that it cannot be used anywhere else.
• Remove fallback entries that point at the provider you stopped using.

• Keep provider keys out of tickets, tasks, comments, prompts, and documents. Paste them only into the AI Providers settings.
• Rotate keys at your provider on your usual schedule, then paste the new key into Atlas.
• Review the usage and cost panel after each change of mode or model.

• People in the workspace use AI features as usual. The choice of provider is an administrator setting.
• People should never paste provider keys into notes, tasks, comments, or support requests.

• After you save a key, the settings show only its first four characters, and the status line reads Your own key with the provider name.
• A key the provider rejects is refused with a message next to the key field, and nothing is saved.
• With the fallback switch off, an AI feature run while the key cannot be used returns an error that names Settings, then AI Providers. With it on, the same feature completes on the Atlas default.
• An AI feature, such as a meeting summary, completes and appears in the usage panel.
• Reset to cloud removes the key, and AI features keep working on the Atlas managed default.
• Someone without owner or administrator access cannot open or change the AI Providers settings.

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

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

• 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

1. 1

   Open Settings -> Security and copy the Atlas ACS URL, metadata URL, and SCIM base URL.

2. 2

   Choose the Okta, Microsoft Entra, Google Workspace, or generic setup guide that matches your identity provider.

3. 3

   Configure SAML in the provider, then paste IdP metadata XML into Atlas or enter Entity ID, SSO URL, and x509 certificate manually.

4. 4

   Create a SCIM token in Atlas, copy the one-time bearer token into the provider, and map userName, name, externalId, and active.

5. 5

   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.

6. 6

   Paste a small JSON export from the provider provisioning logs into Provider log review to inspect aggregate failure and unknown-operation buckets.

• 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

• identity
• groups
• users
• provisioning

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.

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.

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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.

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

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

1. 1

   Open Settings -> Webhooks and create an outbound subscription from the Atlas manage surface.

2. 2

   Choose the allowed event types, enter the receiver endpoint, and store the one-time generated signing secret in the receiver.

3. 3

   Validate HMAC signature, timestamp tolerance, and quick 2xx acknowledgement with a test delivery.

4. 4

   Return to Settings -> Integrations to review summary-only receipt readback, retries, and rollback state.

• 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

• events:read
• webhooks:write
• tokens:manage

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

Outbound event delivery with inbound API access through scoped tokens.

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Dropbox provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: DROPBOX_CLIENT_ID, DROPBOX_CLIENT_SECRET, DROPBOX_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: files.metadata.read, files.content.read, sharing.read.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

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

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Box provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: BOX_CLIENT_ID, BOX_CLIENT_SECRET, BOX_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: root_readwrite, manage_webhook.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• root_readwrite
• manage_webhook

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the OneDrive provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: MICROSOFT_OAUTH_CLIENT_ID, MICROSOFT_OAUTH_CLIENT_SECRET.

3. 3

   Grant only these scopes during authorization: Files.Read.All, Sites.Read.All, offline_access.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• Files.Read.All
• Sites.Read.All
• offline_access

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Stripe provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET.

3. 3

   Grant only these scopes during authorization: customers, subscriptions, invoices, webhooks.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• customers
• subscriptions
• invoices
• webhooks

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Create or select the Salesforce, HubSpot, DocuSign, Adobe, Dropbox Sign provider app in a sandbox workspace.

2. 2

   Configure the required deployment variables: GROWTH_SUITE_*, DOCUSIGN_*, ADOBE_*, DROPBOX_SIGN_*, PANDADOC_*.

3. 3

   Grant only these scopes during authorization: crm objects, signing envelopes, PDF services, webhooks.

4. 4

   Open Settings -> Integrations to validate readiness, connection health, sync logs, retries, and rollback state.

• 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

• crm objects
• signing envelopes
• PDF services
• webhooks

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

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

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

1. 1

   Choose one provider-specific setup group: Dropbox, Box, OneDrive, Stripe.

2. 2

   Configure every deployment variable for the chosen provider group before enabling any connection attempt.

3. 3

   Grant only the scopes needed by that provider path: files, billing, webhooks.

4. 4

   Open Settings -> Integrations to confirm the aggregate card remains execution-gated until provider-specific OAuth, sync, webhook, and sandbox/live proof pass.

• 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

• files
• billing
• webhooks

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

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

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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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