# Asana service accounts and personal access tokens (/integrations/asana-service-account)

Sim accepts an Asana service account token or a personal access token. Service accounts use a separate bot identity; personal access tokens use the permissions of the user who created them.

There are two ways to get a token, and both work in Sim:

- **Service account token** (recommended for teams) — available on Asana **Enterprise** and **Enterprise+** plans, created by a super admin in the Admin Console.
- **Personal access token (PAT)** — created from a user account when the organization’s API policy permits it. For production workflows, create it from a dedicated bot account rather than a personal one.

Paste either token into the same field in Sim. Asana treats tokens as opaque; their format can change.

## Option A: Service account token (Enterprise / Enterprise+) \[#option-a-service-account-token-enterprise--enterprise]

### Prerequisites \[#prerequisites]

You need an Asana **super admin** on an **Enterprise** or **Enterprise+** plan. Service accounts are an organization-level feature — regular users cannot create them.

### Create the service account \[#create-the-service-account]

Open the Asana **Admin Console** and go to **Apps** → **Service accounts**

Click **Add service account**, give it a name (e.g. `Sim Integration`) — this is the name that will appear on tasks and comments the workflows create

Grant the service account **Full Permissions**. Scoped service accounts (for example, ones limited to User Provisioning / SCIM) cannot call the standard Asana API and will fail when you connect them to Sim

Copy the token when it's shown. Asana only displays it once — if you lose it, you'll have to regenerate it — plan to update the credential in Sim at the same time, since the old token stops working once it's replaced.

Warning:

A service account with **Full Permissions** has organization-wide access to all data in your Asana organization, including private projects. Treat the token like an admin password.

## Option B: Personal access token \[#option-b-personal-access-token]

If you're not on an Enterprise plan, a personal access token works identically on the wire. For production workflows, create a dedicated bot user account (e.g. `sim-bot@yourcompany.com`) and generate the PAT from that account — a PAT is tied to the user who created it, inherits only that user's permissions, and stops working if the user is deprovisioned.

Log in as the bot account and open the developer console at [app.asana.com/0/my-apps](https://app.asana.com/0/my-apps)

Click **+ Create new token**, give it a name that describes its use (e.g. `Sim Integration`), and click **Create token**

Copy the token immediately — Asana only shows it once.

Add the bot account to the workspaces and projects your workflows need. A PAT can only see what its user can see.

## Add the token to Sim \[#adding-the-token-to-sim]

Open **Integrations** from your workspace sidebar

Search for "Asana" and open it, then click **Add to Sim** and choose **Add access token**

Paste the token — service account token or personal access token, both work in the same field — and optionally set a display name and description

Click **Add access token**. Sim verifies it with Asana’s `/users/me` endpoint. Validation does not test every project or operation.

If a new token is rejected, check that it was copied correctly, has the required permissions, and is allowed by organization policy. Retry a transient provider failure; replace a revoked or expired token.

The token is encrypted before being stored.

## Use the service account in workflows \[#using-the-service-account-in-workflows]

Add an Asana block to your workflow. In the credential dropdown, your Asana service account appears alongside any OAuth credentials. Configure the operation and its required fields.

The block calls the Asana API (`app.asana.com/api/1.0`) with the token as a standard Bearer credential. There's no impersonation step — the token acts as itself: the service account identity, or the bot user for a PAT.

## Token lifecycle and recovery \[#token-lifecycle-and-recovery]

Service-account tokens act as the organization’s bot identity; PATs act as their creating user. The token is the only credential field: workspace and project IDs are block parameters, and requests use Bearer authentication at `app.asana.com/api/1.0`.

PATs are persistent by default, but organization policy can require expiration. Revocation, regeneration, user deprovisioning, or a configured expiry can invalidate a credential. For a `401`, check the token’s current status and replace it in Sim when needed. Regenerating a service-account token invalidates its predecessor, so update Sim promptly and account for runs during rotation. See [Asana’s token guidance](https://developers.asana.com/docs/personal-access-token).

A scoped service account for SCIM or audit access cannot be substituted for a full-permission credential for these standard API operations. All workflows sharing one token also share its [rate limits](https://developers.asana.com/docs/rate-limits); handle HTTP `429` and respect `Retry-After` before retrying.