1. Overview
The Asana integration brings authorized workspace, user, team, project, task, story, and attachment metadata into a Seedling workspace. Seedling uses that information for source-backed search, operating context, verification, and customer-approved workflows.
A current Seedling workspace administrator establishes one workspace-level Asana connection. The immutable Asana workspace GID, not a name, email, or domain, determines which provider account is attached.
2. Connection options
Both modes use the same tenant-scoped ingestion, source entitlement, review, and deletion controls. Switching credential ownership requires disconnecting and completing deletion before reconnecting; Seedling never converts a connection silently.
- Seedling-managed OAuth app
- An Asana user authorizes the displayed granular read scopes. Seedling stores encrypted access and refresh tokens, rotates short-lived access tokens, validates the exact workspace GID, and periodically reconciles the installation.
- Customer-managed personal access token
- Your organization creates and controls an Asana PAT. The token inherits the authorizing user’s native Asana permissions and remains available as a permanent alternative.
3. Asana data Seedling accesses
The customer-managed PAT path can also stage workspace and project membership context visible to the token owner. The Seedling-managed OAuth path deliberately omits those two unscoped endpoint families instead of requesting Asana Full Permissions.
- Workspace, users, and teams
- Workspace identity and visible user and team profiles used to establish source context.
- Projects and tasks
- Visible active and archived project metadata; task names, descriptions, dates, status, assignees, followers, tags, project placement, and custom-field values.
- Stories and attachments
- Visible task stories and attachment metadata, including authorized links. Seedling does not currently download attachment file bodies.
- Authorization and synchronization
- Workspace GID, granted scopes, encrypted credentials, credential version and expiry, lifecycle state, page checkpoints, sync batches, and bounded failure codes.
4. Seedling-managed OAuth scopes
All requested scopes are granular and read-only. Seedling does not request Full Permissions or scopes that create, update, or delete Asana data. The grant remains bounded by the authorizing user’s native Asana access.
- Workspace catalog
- workspaces:read
- Users and teams
- users:read and teams:read
- Projects and tasks
- projects:read and tasks:read
- Task custom-field values
- custom_fields:read
- Stories and attachments
- stories:read and attachments:read
5. Security and access
- OAuth uses a single-use, ten-minute state record and S256 PKCE; the callback rechecks the authorizing user’s current Seedling workspace-admin role.
- OAuth access and refresh tokens are encrypted in the workspace tenant data plane and never returned to the browser.
- Synchronized content is tenant-scoped, source-entitlement protected, and restricted by default until access can be mapped safely.
- Tokens, authorization codes, native payloads, provider error bodies, and customer content are excluded from URLs, queue payloads, logs, and analytics.
- Generated output cannot bypass Seedling’s human review, verification, and approval gates.
6. Retention and deletion
- Authorization sessions
- Single-use OAuth sessions expire after ten minutes, contain no provider token, and are deleted within one day after expiry or use.
- Connected data
- Synchronized Asana records remain while the connection is active and are removed by a durable, idempotent purge after disconnect or confirmed provider deauthorization.
- Backups
- Deleted data may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.