Asana Admin Setup Guide India — Workspace, SSO, SCIM, Permissions & Security

Asana admin setup goes well beyond creating a few projects and inviting users. A properly configured Asana organisation has a deliberate workspace architecture, SSO authentication tied to your identity provider, SCIM provisioning for automated user lifecycle management, role-based permissions controlling who sees what, and security settings that meet corporate IT standards. This guide covers the complete Asana technical setup for IT administrators in India, from initial provisioning to SSO configuration, custom field governance, and security hardening.

Asana Plan Requirements for Admin Features

Before beginning setup, confirm your Asana plan — admin capabilities are gated by licence tier:

SSO and SCIM require Asana Advanced as the minimum. For Enterprise-grade IT compliance, security and audit capabilities, Asana Enterprise is required.

Part 1 — Initial Organisation Setup

Step 1 — Claim Your Organisation Domain

When Asana is first activated, your account starts as a Workspace. To unlock admin controls, you must upgrade to an Organisation by claiming your company email domain.

1. In Asana Admin Console → Settings → Organisation
2. Under Domain Management, click Verify Domain
3. Add a DNS TXT record provided by Asana to your DNS zone (at your domain registrar or DNS host)
4. Click Verify — Asana confirms domain ownership within a few minutes

Once claimed: any user who signs up for Asana with your company email domain is automatically added to your Asana Organisation rather than creating an independent Workspace. This is critical for licence control and security.

Step 2 — Configure Your Org Admin Team

1. In Admin Console → Members
2. Assign the Organisation Admin role to your IT admin accounts
3. Assign Super Admin role to a backup admin account — in case the primary admin loses access

Recommended admin structure:

• 1–2 Organisation Admins (IT department)
• Optionally 3–5 Division Admins if you have large departments that self-manage their Asana setup

Do not give Organisation Admin access to department heads or end-users — it provides access to all private projects, all members' data, and billing settings.

Step 3 — Set Organisation-Level Settings

In Admin Console → Settings:

New member defaults:

• Default project permissions for new members: choose between Can comment (read + comment, cannot edit), Can edit, or No access for new projects. For most organisations: set default to Can comment and explicitly grant edit access per project.
• Default new member role: Member (not Guest)

Member management:

• Enable Require approval for joining — prevents employees from inviting external users without admin awareness
• Disable Allow members to invite guests if you want centralised guest management (useful for client-facing teams with strict access control)

Project creation:

• Restrict project creation to Members only (not Guests)
• Optionally restrict project creation to specific teams to prevent workspace sprawl

Part 2 — SSO Configuration

Single Sign-On (SSO) via SAML 2.0 is supported in Asana Advanced and above. It connects Asana authentication to your identity provider — users log in to Asana using their existing corporate credentials, not a separate Asana password.

Supported Identity Providers (IdPs)

Asana has tested integrations with:

• Azure AD (Microsoft Entra ID) — most common in Indian enterprises using M365
• Google Workspace — most common in Indian companies standardised on Google
• Okta — common in larger enterprises
• OneLogin
• Generic SAML 2.0 — for other IdPs

SSO Setup with Azure AD (Microsoft Entra)

1. In Azure Portal → Azure Active Directory → Enterprise Applications:

   • Click New Application → Create your own application
   • Name: "Asana"
   • Select Integrate any other application you don't find in the gallery (Non-gallery)
   • Click Create

2. In the Asana enterprise application → Single sign-on → SAML: Configure the basic SAML settings:

   • Identifier (Entity ID): https://app.asana.com/-/saml/consume
   • Reply URL (ACS URL): https://app.asana.com/-/saml/consume
   • Sign-on URL: https://app.asana.com/-/saml/consume

3. In SAML Signing Certificate: Download the Federation Metadata XML file from Azure AD.

4. In Asana Admin Console → Security → SAML:

   • Enable SAML
   • Upload the Azure AD Federation Metadata XML
   • Asana parses the IdP entity ID, SSO URL and certificate automatically

5. Map user attributes: In Azure AD, configure the SAML user attributes:

   • emailaddress → user.mail
   • givenname → user.givenname
   • surname → user.surname
   • name → user.displayname

6. Assign the Asana application to users or groups in Azure AD before testing.

7. Test SSO before enforcing it — use the Azure AD Test SAML button to verify the flow without locking out users.

SSO Setup with Google Workspace

1. In Google Admin Console → Apps → Web and mobile apps → Add App → Add custom SAML app:

   • App name: Asana
   • Download the IdP metadata (Google's SSO URL and certificate)

2. Configure SAML service provider details:

   • ACS URL: https://app.asana.com/-/saml/consume
   • Entity ID: https://app.asana.com/-/saml/consume
   • Name ID format: Email
   • Name ID: Basic Information → Primary email

3. Attribute mapping:

   • email → Primary email
   • firstName → First name
   • lastName → Last name

4. In Asana Admin Console → Security → SAML: Upload the Google IdP metadata XML downloaded in step 1.

5. In Google Admin Console, assign the Asana app to the relevant Organisational Unit or group of users.

Enforcing SSO

Once SSO is tested and working, in Asana Admin Console → Security → SAML:

• Set SAML enforcement to Required (not Optional)
• When Required: users cannot log in with email/password — only via your IdP

Before enforcing: confirm that every user in your Asana organisation has an account in your IdP (Azure AD / Google Workspace) with the same email address as their Asana account. Mismatched emails lock users out immediately upon enforcement.

Part 3 — SCIM Provisioning

SCIM (System for Cross-domain Identity Management) automates user provisioning in Asana based on your IdP. When a new employee is added to your IdP group for Asana, they are automatically provisioned an Asana licence. When an employee leaves and is removed from the IdP, their Asana access is deprovisioned automatically.

SCIM requires Asana Advanced or higher and an SSO configuration already in place.

SCIM Setup with Azure AD

1. In Asana Admin Console → Security → SAML → Provisioning:

   • Click Generate SCIM API token
   • Copy the token (you will not see it again — save it securely)
   • Note the SCIM base URL: https://app.asana.com/api/1.0/scim

2. In Azure Portal → Enterprise Application (Asana) → Provisioning:

   • Set Provisioning Mode to Automatic
   • Tenant URL: https://app.asana.com/api/1.0/scim
   • Secret Token: paste the SCIM API token from step 1
   • Click Test Connection → confirm successful

3. Configure Attribute Mapping: Verify the default attribute mappings are correct:

   • userName → user.mail
   • displayName → user.displayName
   • givenName → user.givenName
   • familyName → user.surname
   • active → Switch([IsSoftDeleted], "False", "True", "True", "False")

4. Set Scope: Under Settings → Scope, choose Sync only assigned users and groups. Assign the relevant Azure AD group (your Asana users group) to the enterprise application.

5. Enable Provisioning: Set Provisioning Status to On. Azure AD will sync users on the next provisioning cycle (typically within 40 minutes for the first run).

SCIM Setup with Google Workspace

Google Workspace does not support SCIM provisioning for third-party apps directly through the Admin Console. Options:

• Use Okta as an intermediary IdP (Google Workspace → Okta → Asana SCIM)
• Use Google Workspace with Just-in-Time (JIT) provisioning — users are automatically created in Asana on their first SSO login, without SCIM. Users are not automatically deprovisioned, however — you manage deprovisioning manually or via the Asana Admin Console.

For most Google Workspace organisations in India: JIT provisioning is sufficient. Configure auto-provisioning in Asana Admin Console → Settings → New Member Settings → Automatically add members from your domain.

What SCIM Manages

With SCIM active, you manage Asana users through your IdP:

• Add user to Asana: Add user to the Asana IdP group → SCIM creates the user in Asana within one provisioning cycle
• Remove user from Asana: Remove user from the IdP group or deactivate in IdP → SCIM deactivates the Asana account (their tasks remain, they cannot log in)
• Update user attributes: Change display name or email in IdP → SCIM updates the Asana account

Part 4 — Workspace Architecture

A well-structured Asana workspace prevents the sprawl of random projects, misnamed teams and orphaned tasks that accumulates when teams are self-organising without governance.

Teams Structure

Asana Teams are the top-level organisational unit. Team membership controls which projects users can discover and join. Recommended team structure for a 50-100 person Indian company:

Organisation: Your Company Name
├── Marketing
├── Sales
├── Engineering / Product
├── Operations
├── HR & Admin
├── Finance
└── [Client Name] — one team per key client (for client-facing work)

Rules:

• Employees are members of their functional team plus any cross-functional project teams
• Client teams contain the relevant internal staff and the client as a Guest
• Create a new Team only when it has more than one project — single-project teams are unnecessary overhead

Custom Fields Governance

Custom fields in Asana are Organisation-wide when created as Global Fields — they appear in every project in the org. Uncontrolled custom field creation leads to dozens of near-duplicate fields (Priority, priority, Prioritisation, Urgency) that clutter every project.

Establish a standard custom field library before go-live:

In Admin Console → Custom fields: Mark standard fields as Locked to Admins so team members cannot edit the field definition (though they can set the value on tasks).

Project Templates

Project templates are the most impactful admin setup investment. A template means every new project of a given type starts with the right sections, custom fields, task list and automation rules pre-configured.

Priority templates to build before go-live:

1. Marketing Campaign — sections: Brief → Pre-launch → Launch → Post-launch; fields: Campaign type, Budget, Launch date; form for brief intake
2. Product Feature — sections: Discovery → Design → Development → QA → Release; fields: Priority, Effort, Sprint
3. Client Project — sections: Kickoff → In Progress → Review → Delivered; fields: Client, Budget, Status
4. Event Planning — sections: Planning → Logistics → Execution → Wrap-up; fields: Event type, Location, Attendees
5. Hiring Pipeline — sections: Applied → Screened → Interviewed → Offered → Onboarded; fields: Role, Department, Hiring manager

To create a template: build the project with all sections, fields and placeholder tasks → Project Settings → Save as Template.

Part 5 — Permissions and Security Hardening

Project Privacy Settings

Every Asana project has a privacy setting:

• Public to organisation — any org member can find and join the project
• Private to project members — only explicitly invited members can see the project
• Comment-only for non-members — visible but read-only to non-members

Recommended defaults:

• Internal operational projects: Public to organisation
• Client-facing projects: Private to project members (team + client only)
• HR, finance, legal projects: Private to project members (restricted to relevant staff)
• Executive or confidential projects: Private + disable export

Guest Access Configuration

Guests in Asana are external users (clients, vendors, contractors) added to specific projects without access to your full Asana organisation.

In Admin Console → Security → Guest Access:

• Enable guest access: Yes
• Guests can be invited by: Members and above (or restrict to Admins only)
• Guest session duration: set to 90 days (guests must be re-invited after 90 days if needed — this prevents perpetual client access to completed projects)

When inviting a client as a Guest:

• Create a dedicated project for their deliverables
• Share only that project with the Guest
• Set their project permission to Comment only if you don't want them editing tasks

Data Export and Audit Controls

In Admin Console → Security:

• Allow data export: Restrict to Admins only. Do not allow all members to export org-wide task data.
• Allow users to download attachments: Enable (usually required for productivity), but log via audit log if available.
• Session duration: Set to 24 hours for security-conscious environments; 7 days for convenience-first organisations.
• Two-factor authentication (2FA): If SSO is not enforced, require 2FA for all members. If SSO is enforced, 2FA is handled at the IdP level.
• Audit log (Enterprise): Enable and connect to your SIEM if required for compliance (RBI, ISO 27001, SOC 2).

Password and Login Policy (for non-SSO accounts)

If some users authenticate with email/password rather than SSO:

• Minimum password length: 12 characters
• Password expiry: 90 days
• Block common passwords: enabled

For full security: enforce SSO and eliminate password-based Asana logins entirely.

Part 6 — Integrations Setup

Google Workspace Integration

1. Install Asana for Gmail from Google Workspace Marketplace → admins install org-wide
2. Install Asana for Google Drive — allows attaching Drive files directly to Asana tasks
3. Enable Asana for Google Calendar — task due dates appear in Google Calendar

In Asana Admin → Integrations: enable Google Workspace integrations for all org members.

Microsoft 365 Integration

1. Install Asana for Outlook from Microsoft AppSource → push via Intune or M365 Admin for all users
2. Enable Asana for Teams from the Microsoft Teams App Store — allows creating Asana tasks from Teams messages and viewing project status in Teams channels

In Asana Admin → Integrations: Microsoft 365 integration requires OAuth consent from an M365 Global Admin.

Slack Integration

1. In Slack workspace settings → Apps → install Asana
2. In Asana Admin Console → Integrations → Slack: connect the workspace
3. Configure notification preferences: per-project notification rules can be set by project admins (e.g. task completion in "Sales Projects" notifies the #sales-wins channel)

Zapier / Make (for custom integrations)

For connections not available natively (e.g. Zoho CRM, custom internal tools, WhatsApp via Twilio), use Zapier or Make (formerly Integromat) to build automation between Asana and other systems. Asana has native apps in both platforms with full API coverage for task creation, updates and completion events.

Post-Setup Admin Checklist

Complete before go-live:

Identity and access:

• Domain claimed and verified
• SSO configured and tested with at least 5 pilot users
• SCIM provisioning active and verified (one test user provisioned via IdP group add)
• SSO enforcement set to Required
• Org Admin accounts confirmed (minimum 2 admins)

Workspace structure:

• Teams created matching organisational structure
• Standard custom field library built and locked to Admins
• Priority project templates built and tested
• Default project permissions configured

Security:

• Guest access settings configured
• Data export restricted to Admins
• Session duration set
• 2FA enforced (if SSO is not enforced for all users)
• Audit log enabled and reviewed (Enterprise plan)

Integrations:

• Google Workspace or M365 integration installed org-wide
• Slack connected and test notification confirmed
• GitHub / HubSpot / Salesforce connected (if applicable)

User readiness:

• All users provisioned via SCIM or manual invite
• Admin training completed
• Project manager training completed
• Team member training completed

Frequently Asked Questions

How do I remove a user from Asana when they leave the company? With SCIM: deactivate the user in your IdP (Azure AD / Okta) — SCIM deactivates their Asana account automatically within one provisioning cycle. Without SCIM: in Admin Console → Members → find the user → Deactivate Member. Their tasks remain and can be reassigned; they cannot log in.

Can Asana SSO work with both Azure AD and Google Workspace at the same time? No. Asana supports one SAML IdP at a time. If your organisation uses both Azure AD and Google Workspace, choose the primary IdP (typically whichever houses your corporate directory) for Asana SSO. Users who are in both systems authenticate via the configured IdP.

What is the difference between Deactivate and Remove in Asana member management? Deactivate: the user cannot log in but all their tasks, projects and comments are preserved. Assign their tasks to another user before or after deactivation. Remove: permanently removes the user from the organisation — tasks become unassigned. Always Deactivate rather than Remove for departing employees.

Can we have different SSO configurations for different departments? No. SSO in Asana is configured at the Organisation level — one IdP for the entire org. Department-level SSO differentiation is not supported. If you need different authentication policies per group, manage this at the IdP level via Conditional Access policies (Azure AD) or Context-Aware Access (Google Workspace).

How many custom fields can we have in Asana Advanced? Asana Advanced has unlimited custom fields. Asana Starter is limited to 15 custom fields per organisation. If your team needs more than 15 fields, Advanced is required.

Can guests see our internal projects? No. Guests only see projects they have been explicitly invited to. They cannot search or discover other projects in the organisation, cannot see team members outside their shared projects, and cannot access the Admin Console or organisation settings.

Is Asana data stored in India? Asana's default data centres are in the United States (AWS us-east-1). Data residency (in-region storage in the EU or other regions) is available only on Enterprise+ plans. For Indian businesses with regulatory data localisation requirements (RBI, DPDP Act), consult Asana's Enterprise+ team or Cloudfy for guidance on the data residency programme.

Need help setting up Asana for your organisation? Contact Cloudfy Systems — India's certified Asana Solutions Partner. We handle workspace architecture, SSO configuration, SCIM setup, template build, integrations and admin training. INR pricing, GST invoice, typical deployment in 3–7 working days.