> ## Documentation Index > Fetch the complete documentation index at: https://support.configview.com/llms.txt > Use this file to discover all available pages before exploring further. # Asana setup ConfigView reads your Asana organization through the Asana API using a **service account token** (Enterprise and Enterprise+ plans) or, on other plans, a **personal access token** belonging to a workspace admin. You will end up with **1 secret** in ConfigView (`ASANA_ACCESS_TOKEN`) when setup is complete. Two more are optional: `ASANA_AUDIT_TOKEN` and `ASANA_WORKSPACE_GID`. > **Scope of this integration today.** ConfigView reads who is in your Asana workspaces: members, admins, guests (including people from outside your company's email domains), view-only users and deactivated accounts. It also reads your teams, who belongs to each one, and who is a team admin. On Enterprise+ it reads the audit log too: apps people authorized, data exports, role and security-setting changes, sign-ins and deletions. It never reads tasks, projects, comments, messages or files, or even their names. ConfigView only reads. It never creates, changes or deletes anything. *** ## Step 1: Open the Asana page in ConfigView Open ConfigView in a second browser tab and leave it open: `https://{companyname}.configview.com/admin/integrations/asana` Asana shows a new token once, when you create it, so paste it straight into ConfigView instead of keeping it in a notes file. *** ## Step 2: Create the token ### Enterprise and Enterprise+: a service account (recommended) A service account sees your whole organization, doesn't belong to a person who might leave, and is the only kind of token that can read the audit log. 1. Sign in to Asana as a **super admin** 2. Open the **Admin console → Apps → Service accounts** 3. Click **Add service account** and name it `ConfigView` 4. Under permissions, choose **Full permissions**. Asana's service-account scopes cover only SCIM, the audit log, exports, workspace events and AI Studio usage. Reading users and teams needs Full permissions, and Asana has no read-only version of it. ConfigView only ever sends GET requests 5. Copy the token. Asana shows it only once 6. Switch to the ConfigView tab, paste it into `ASANA_ACCESS_TOKEN` under **Credentials**, and click the save icon ### Optional: a separate token for the audit log If your security team would rather keep audit access on its own credential, create a **second** service account with only the **Audit Logs** scope and paste its token into `ASANA_AUDIT_TOKEN`. The audit log collector then uses it, and everything else uses `ASANA_ACCESS_TOKEN`. ### Other plans: a personal access token Personal access tokens work on every plan, but they see only what their user sees. 1. Sign in as a **workspace admin**. A shared admin account that won't leave is the safer choice 2. Open [app.asana.com/0/my-apps](https://app.asana.com/0/my-apps) and click **Create new token** 3. Name it `ConfigView`, agree to the terms and click **Create token** 4. Copy the token into `ASANA_ACCESS_TOKEN` and click the save icon With a personal access token, teams the admin isn't in may be missing (and so may their members), and the audit log is skipped. The health check reports a `warn` if the token's user isn't an admin. ### Optional: read only some workspaces By default ConfigView reads every workspace the token can see. To read just one, put its numeric ID in `ASANA_WORKSPACE_GID`. To see the IDs, open `https://app.asana.com/api/1.0/workspaces` while you're signed in to Asana. To read several, separate the IDs with commas. *** ## Step 3: Connect and verify 1. Back on `https://{companyname}.configview.com/admin/integrations/asana`, confirm the credentials show as saved 2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**: | Script | Notes | | - | - | | **Workspaces** | Every Asana workspace and organization the token can see: name, whether it's an organization tied to the company's email domains, and which domains those are. | | **Members and Guests** | Everyone in each Asana workspace: name, email, whether they're an admin, a guest, view-only or deactivated, whether their address is outside the company's email domains, and when they joined. | | **Teams** | Teams in each Asana organization: name, whether the team is public to the organization or private, whether it's endorsed, and who may invite members or guests and remove people. Team descriptions are never read. | | **Team Members** | Who belongs to each Asana team, and whether they're a team admin, a guest, or have limited access. | | **Audit Log** | Asana's audit log (Enterprise+ with a service account): sign-ins, apps and access tokens people authorized or revoked, data exports, admin and role changes, security settings and deletions. Each event records who did it, from which IP address, and what changed. Task and project names are never stored. Kept as a growing history beyond Asana's 90 days. | 3. Click **Verify now**. The health check confirms the token, signs in, lists the workspaces it can see, checks whether the token's user is an admin, then reads one record from each list in each workspace. If a check fails: * **Auth fails with 401.** The token was mistyped, revoked, or expired. Your admins can set personal access tokens to expire, and a service account's token stops working when the service account is deleted. * **"Workspaces the token can see" fails.** If `ASANA_WORKSPACE_GID` is set, it doesn't match any workspace the token can see. The message lists the IDs it can see. * **"Token's user is a workspace admin" warns.** The personal access token belongs to someone who isn't an admin, so private teams and their members will be missing. * **Audit log is skipped with 402 or 403.** Expected unless you're on Enterprise+ (or on Enterprise with the Compliance Management add-on) and the token is a service account's. * **Teams and Audit log are skipped for a workspace.** It's a personal workspace, not an organization, and Asana has no teams or audit log there. *** ## Data Tables Once the scripts run, these tables are created in your database. Each includes a `run_at` column for historical tracking, and a `raw_json` column holding the record as Asana returned it, minus the fields listed under *What isn't collected*. Every table keeps only the newest run, except `asana_audit_log_events`, which keeps every event it has ever read. | Table | Source | Key Columns | | - | - | - | | `asana_workspaces` | `GET /workspaces` | workspace\_gid, name, is\_organization, email\_domains | | `asana_users` | `GET /workspaces/{id}/workspace_memberships` | membership\_gid, workspace\_gid, workspace\_name, user\_gid, name, email, email\_domain, is\_external, is\_active, is\_admin, is\_guest, is\_view\_only, vacation\_start\_on, vacation\_end\_on, created\_at | | `asana_teams` | `GET /workspaces/{id}/teams` | team\_gid, workspace\_gid, name, visibility, endorsed, member\_invite\_access, guest\_invite\_access, join\_request\_access, member\_removal\_access, content\_management\_access, edit\_name\_access, edit\_visibility\_access | | `asana_team_memberships` | `GET /teams/{id}/team_memberships` | membership\_gid, workspace\_gid, team\_gid, team\_name, user\_gid, user\_name, user\_email, is\_guest, is\_admin, is\_limited\_access | | `asana_audit_log_events` | `GET /workspaces/{id}/audit_log_events` | event\_gid, workspace\_gid, created\_at, event\_type, event\_category, actor\_type, actor\_gid, actor\_name, actor\_email, resource\_type, resource\_subtype, resource\_gid, resource\_name, resource\_email, app\_name, old\_value, new\_value, context\_type, api\_auth\_method, client\_ip\_address, user\_agent, oauth\_app\_name, rule\_name, on\_behalf\_of\_user\_id, details\_json | *** ## Things worth knowing **`is_external` compares addresses with your email domains.** An Asana organization is tied to one or more company email domains (`asana_workspaces.email_domains`). `is_external = 1` means the person's address is on some other domain. They're usually a guest from a customer, agency or contractor. In a personal workspace, which has no domains, it's empty. **Deactivated people stay in the list.** When someone is removed from an organization, their membership shows `is_active = 0` instead of disappearing. That's how the deactivated-users question finds them. **Asana doesn't report last sign-in.** Membership records carry no sign-in date. On Enterprise+, sign-ins are in the audit log (`event_type = 'user_login_succeeded'`). **The audit log is a growing history.** Asana keeps audit events for only 90 days. The first run reads all 90 days, oldest first. After that, each run picks up from the newest stored event, so nothing is read twice and nothing is ever deleted. After a few months, ConfigView holds more history than Asana does. **Apps people authorized come from the audit log.** Asana has no API that lists the apps connected to an organization. ConfigView rebuilds the list from `user_app_authorized` / `user_app_revoked` events and from the OAuth app named on API activity (`oauth_app_name`). These feed the connection map. Without the audit log, ConfigView can't see Asana's connected apps. **Content names are dropped from audit events.** An event about a task, project, goal or file keeps its type and ID, but `resource_name` is left empty. Names are kept for people, teams, workspaces and other admin objects. **Rate limits are per token.** Asana allows 150 requests a minute on free domains and 1,500 on paid ones, for each token. ConfigView paces itself at 100 a minute and reads one team at a time. A large organization's team memberships take a few minutes. Give ConfigView its own token so it doesn't share a quota with another integration. ## What isn't collected * Tasks, projects, portfolios, goals, messages, comments and attachments, including their names * Team descriptions, profile photos and custom fields * The SAML response carried on sign-in events * Token values of any kind * Webhooks: Asana only lists the webhooks the calling token's own app created, never the organization's This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.