Summary and recommendation
Asana user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Asana's Admin Console gives Super Admins and Admins a central place to invite members, monitor seat usage, and remove departing users - but the depth of control depends heavily on plan tier. SCIM-based lifecycle automation is gated behind Enterprise, meaning teams on Starter or Advanced must handle provisioning and deprovisioning manually.
Every app in a well-governed stack needs a clear offboarding path; in Asana, that path runs entirely through the Admin Console until Enterprise is in place.
Quick facts
| Admin console path | Profile photo (top-right) → Admin Console |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Super Admin | Full access to all Admin Console settings including SSO/SAML configuration, SCIM setup, security enforcement, domain management, billing, and all user/team management actions. Can claim admin permissions on any work item in the org. | Cannot be a Guest. Cannot exist without a verified company email domain. | Starter and above (domain verification required; SSO/SCIM controls require Enterprise) | Counts as a paid Member seat | Admins (non-Super) cannot configure SSO or SCIM; those controls are Super Admin-only. Domain must be DNS-verified before first Super Admin can be assigned. |
| Admin | Can manage users, teams, and limited security settings via Admin Console. Can invite/deactivate members, export member lists, and view seat usage. | Cannot configure SSO, SAML, or SCIM. Fewer security controls than Super Admin. | Starter and above | Counts as a paid Member seat | Admins have limited security privileges only; SSO/SCIM configuration is restricted to Super Admins. |
| Billing Owner | Can view billing information and access tutorials in the Admin Console. | Cannot manage users, teams, or security settings. | Starter and above | Counts as a paid Member seat | Role is limited to billing visibility only; no user management capability. |
| Member | Can create and manage tasks and projects they have access to. Can view names and email addresses of other members and guests via team settings. Can access projects and tasks made public to the organization. | Cannot access Admin Console. Cannot manage org-level settings. | All plans (Personal/free up to 2 users; paid plans unlimited members) | Counts as a paid seat on Starter, Advanced, Enterprise, Enterprise+ | Anyone who signs up with an approved organization email domain automatically becomes a Member without an explicit invite, which can cause unexpected seat consumption. |
| Guest | Limited to projects and tasks explicitly shared with them. Can only join teams by invitation. Cannot see org-wide member lists or access public org projects. | Cannot become an Admin. Cannot access org-wide resources. Cannot see or invite other members unless explicitly permitted by admin settings. | All plans (guests are external collaborators with non-org email domains) | Guests do not consume paid Member seats when accessing a single project; may count as billable if they access multiple projects on paid plans depending on plan configuration. | If a guest joins multiple projects or needs broader access, Asana may count them as a billable user on paid plans. Admins can restrict who can invite guests via Admin Console settings. |
Permission model
- Model type: hybrid
- Description: Asana uses a contextual, hybrid permission model. Workspace-level roles (Super Admin, Admin, Member, Guest) govern Admin Console access and org-wide controls. Object-level permissions (Admin, Editor, Commenter, Viewer for projects; Editor, Viewer for goals) are set per project, portfolio, or goal. There are no custom org-wide RBAC groups or custom roles; governance relies on the four built-in workspace roles combined with per-project and per-team privacy settings.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Workspace role (4 tiers) + per-object access level (project: Admin/Editor/Commenter/Viewer; goal: Editor/Viewer). Team privacy settings (public vs. secret) add a further layer. No global permission groups or attribute-based access control.
How to add users
- Log in as a Super Admin or Admin.
- Click your profile photo in the top-right corner and select 'Admin Console'.
- Navigate to the 'Members' tab.
- Click 'Add members' or the invite button.
- Enter the user's email address.
- Assign the appropriate role (Member, Admin, etc.) if prompted.
- Send the invitation; the user receives an email to accept and join the organization.
Required fields: Email address
Watch out for:
- Users who sign up with an approved organization email domain join automatically without an explicit invite, which can consume paid seats unexpectedly.
- Admin Console access for inviting users requires Starter plan or above; free Personal plan has no Admin Console.
- Pending invites are visible in the Members tab and count toward seat visibility but not necessarily billing until accepted (verify per plan).
- Guests (external email domains) can only be invited to specific projects or teams, not the org directly.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Admin Console → Members → Import (CSV user import; available on Advanced, Enterprise, and Enterprise+ plans as of October 2024) |
| Domain whitelisting | Yes | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SCIM 2.0 via Service Account token; SSO must be configured first) |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Asana does not offer a permanent hard-delete of a user account initiated by an org admin through the standard Admin Console UI. The standard action is deprovisioning/deactivation, which revokes access and frees the seat. Deactivated accounts can be restored by an admin. When removed via the API using a Service Account Token, the behavior mirrors the SCIM Delete endpoint (full deprovision). Private resources not made public before removal may become inaccessible.
- Log in as a Super Admin or Admin.
- Click your profile photo in the top-right corner and select 'Admin Console'.
- Navigate to the 'Members' tab.
- Search for the user to be removed.
- Click the three-dot (•••) menu next to their name.
- Select 'Remove' from the options dropdown.
- Optionally check the box to create a new private project containing the user's assigned tasks for reassignment review.
- Optionally select 'Include completed tasks' to include finished tasks in the reassignment project.
- Choose an active member to be the new owner of the reassignment project.
- Click 'Remove' to confirm and finalize deprovisioning.
| Data impact | Behavior |
|---|---|
| Owned records | When a user is deprovisioned, a private project containing their previously assigned tasks is automatically generated and assigned to the admin or a chosen active member for review and reassignment. Tasks, projects, messages, files, and comments the person created remain intact in the org. |
| Shared content | Shared projects and tasks the user was a collaborator on remain intact. The user is removed as a collaborator/assignee. Historical comments and activity logs are preserved. |
| Integrations | If removed via API using a Personal Access Token (PAT), ownership of the user's resources transfers to the PAT owner rather than the admin specified in the Admin Console. Private resources (visible only to the removed user) must be made public manually before removal or they become inaccessible. |
| License freed | Deactivating a member in the Admin Console frees the paid seat. The seat becomes available for reassignment. Removing a user from a team only (not org-wide deprovisioning) does not free the seat. |
Watch out for:
- Removing a user from a team does not remove them from the organization; they may still have access to projects they were directly invited to.
- Deprovisioning disconnects the user from all completed tasks across all projects, which can disrupt historical audit trails. Admins have reported needing to restore accounts to recover this association.
- Private tasks or projects visible only to the removed user become inaccessible after removal unless made public beforehand.
- Deactivated accounts can be restored by an admin; the account is not permanently deleted via the UI.
- Org-wide removal requires Admin or Super Admin role; team-level removal can be done by team admins or members but does not constitute full deprovisioning.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Member seat (paid) | Full access to paid plan features. Applies to all internal users (Members, Admins, Super Admins, Billing Owners) on Starter, Advanced, Enterprise, and Enterprise+ plans. | Starter: $10.99/user/month (annual) or $13.49/user/month (monthly). Advanced: $24.99/user/month (annual) or $30.49/user/month (monthly). Enterprise: custom pricing (reported minimum ~$35/user/month). Enterprise+: custom pricing (reported ~$45/user/month). |
| Guest (non-billable collaborator) | Limited access to explicitly shared projects and tasks only. External email domain users. Do not consume a paid Member seat when accessing a single project. | No additional seat cost for standard guest access. May become billable if guest accesses multiple projects on paid plans depending on plan configuration. |
| Personal plan user (free) | Core task/project features. Up to 2 users. No Admin Console access. | $0 |
- Where to check usage: Admin Console → Members tab (shows count of active members, guests, pending invites, and available seats). Admin Console → Insights tab (shows daily engagement data, active users, and team activity).
- How to identify unused seats: Admin Console → Insights tab provides daily data on which individuals are using Asana the most and tracks project/task activity over time, enabling identification of inactive or low-usage accounts. Member list can be exported to CSV for offline analysis.
- Billing notes: Seats are purchased in bundles: minimum 2 seats on paid plans; teams of 2–5 can add one at a time; above 5 members, seats must be purchased in 5-seat increments up to 30 users; above 30 users, increments of 10; above 500 users, increments of 50. Annual billing is required for lowest per-seat price. Non-profits receive 50% discount on Starter and Advanced annual plans. Enterprise and Enterprise+ pricing is not publicly listed and requires sales engagement. SCIM provisioning is bundled with Enterprise/Enterprise+ and is not available as a standalone add-on.
The cost of manual management
Manual provisioning in Asana carries three compounding risks. First, any user who signs up with an approved org email domain joins automatically without an explicit admin invite, consuming a paid seat without visibility.
Second, removing a user from a team does not remove them from the org - full deprovisioning requires a separate action in the Members tab. Third, deprovisioning disconnects the user from all historical completed tasks, which can break audit trails; admins have reported restoring accounts solely to recover that task history.
What IT admins are saying
The most consistent friction reported by Asana admins centers on the Enterprise paywall for SCIM. At $24.99/user/month, the Advanced plan is a premium tier, yet it offers only SAML JIT provisioning - no automated deprovisioning, no group sync.
Teams that need lifecycle automation face a significant cost jump to Enterprise with custom pricing. Seat bundle increments (5-seat steps up to 30 users, then 10-seat steps) add further waste when headcount does not align to bundle sizes.
Common complaints:
- No SCIM on Advanced plan despite being a premium tier at $24.99/user/month; SCIM is locked behind Enterprise, forcing a significant cost jump for basic user lifecycle automation.
- Must contact sales for any Enterprise or Enterprise+ pricing; no public pricing page for these tiers.
- JIT provisioning via SAML is available on lower tiers but is less robust than full SCIM (no automated deprovisioning or group sync without SCIM).
- Removing a user from the org disconnects them from all historical completed tasks, breaking audit trails; admins have reported restoring accounts just to recover task history.
- Seat bundle increments (5-seat steps up to 30, then 10-seat steps) mean teams pay for unused seats when headcount does not align to bundle sizes.
- Users who sign up with an approved org email domain join automatically without an explicit admin invite, causing unexpected seat consumption.
- Admins (non-Super) cannot configure SSO or SCIM, requiring Super Admin elevation for security-critical provisioning tasks.
- Free plan (Personal) has no Admin Console, making it difficult to manage or remove users who have left the organization without upgrading.
The decision
Manual administration is viable for smaller teams with stable headcount and an Admin or Super Admin who can run regular membership audits. The Insights tab provides daily activity data and the Members tab supports CSV export, giving enough signal to identify inactive accounts.
However, any org with frequent onboarding and offboarding, or with compliance requirements around timely deprovisioning, will hit the limits of manual management quickly. The absence of SCIM below Enterprise is the single most important factor in that decision.
Bottom line
Asana's manual admin tooling is functional but requires discipline: every app in your stack needs a defined offboarding owner, and in Asana that means a Super Admin running explicit deprovisioning steps - not just team removal.
The automatic seat consumption from org-domain signups and the audit-trail risk on user removal are the two operational gaps most likely to cause problems at scale.
Teams that can absorb those risks on Starter or Advanced will manage; teams that cannot should plan for Enterprise from the start.
Automate Asana workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
