Asana setup

Before connecting Asana

Use this page when the customer wants WebRiskOps to create or update Asana tasks for report findings or fix tasks. Asana is cloud-only, so setup should focus on the customer-owned workspace, project, section, tags, custom fields and task permissions instead of private-network checks. Start from `/settings` after Cloud and self-hosted integrations confirms Asana is a cloud target. Do not save an Asana token until the destination workspace, project, section mapping, auth summary and revoke path are clear.

Connect an Asana workspace and project

Follow the path `Cloud and self-hosted integrations → Asana cloud target → Workspace and project mapping → Work management export → Revoke or fallback`.

1. Open /settings and review Integration status, then choose Asana setup. Result: provider_key is recorded as asana_cloud before workspace fields are requested.
2. Confirm Asana is a cloud-only target and leave base_url empty. Result: deployment_mode stays cloud and self-hosted network checks are not shown for Asana.
3. Choose the customer-owned Asana workspace and authorize with the supported auth_method. Result: WebRiskOps can list only the workspaces, projects, sections, tags and users the customer allowed.
4. Select workspace_id and project_id for the task destination. Result: future work management exports know which Asana project owns the task.
5. Confirm optional section_id, tags, assignee and custom_fields when the workspace exposes them. Result: WebRiskOps can route tasks without requesting unrelated Asana administration access.
6. Save only when the workspace, project and auth summary match the customer workflow. Result: Asana is available to work management export without exposing token values in documentation or support messages.
7. If PROVIDER_AUTH_REQUIRED appears, reconnect Asana before retrying. Result: the target stays blocked until valid cloud credentials exist.
8. If PROVIDER_SCOPE_UNAVAILABLE appears, adjust the Asana authorization or choose portable fallback. Result: tasks are not created without the workspace, project and task permissions Asana requires.
9. Continue to Work management export after setup. Result: workspace_id, project_id, section_id, tags, assignee and custom field mapping use the same Asana provider record.

Configure Asana authorization

Asana setup should collect only the workspace and task access the customer needs.

• `asana_cloud` is the supported Asana provider key.
• `base_url` should stay empty because Asana does not have a self-hosted target.
• `auth_method` should identify the supported Asana OAuth or token flow before a credential is saved.
• `scopes` should allow workspace, project, section, task, tag, custom field and user lookup for the selected workspace.
• `workspace_id`, `project_id` and optional `section_id` should be visible before Asana appears in work management export.
• Revoke access in Asana first, then disconnect the Asana target in WebRiskOps so historical tasks keep references without keeping live credentials.

Ready Asana integration states

Continue only when the task destination is clear.

• Cloud target ready means `provider_key` is `asana_cloud` and `deployment_mode` is cloud.
• Workspace ready means `workspace_id` belongs to the customer-owned Asana workspace.
• Project ready means `project_id` identifies the Asana project that should receive tasks.
• Optional routing ready means section_id, tags, assignee and custom_fields match the customer's workflow when those fields are available.
• Scope ready means Asana can create tasks and read the project, section, tag, custom field and user metadata needed for mapping.

Blocked Asana setup states

Blocked Asana setup should explain exactly what to fix.

• `PROVIDER_AUTH_REQUIRED` means reconnect Asana before saving or retrying export.
• `PROVIDER_SCOPE_UNAVAILABLE` means the token cannot access the selected workspace, project, sections, task fields, tags or users.
• A non-empty `base_url` means the customer is trying to use an unsupported self-hosted Asana target.
• Missing workspace_id or project_id means work management export cannot place the task.
• Missing section, tag, assignee or custom field mapping should fall back to the selected project or portable export notes when Asana does not expose matching fields.

Continue after Asana setup

Continue to Work management export when the Asana project is ready. Use Status sync and duplicate handling when an Asana task already exists, Portable export fallbacks when Asana permissions cannot be made safe, YouTrack Cloud and Server setup when the team tracks remediation in YouTrack, or ClickUp setup when the team uses ClickUp.