Skip to main content
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

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 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:
  1. 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.

​
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