Asana integration nuances (permissions)

Last updated: December 30, 2025

Overview

Merge’s Asana integration syncs Projects, Sections, Tasks, and Subtasks. Asana visibility is driven by a mix of project access and task collaboration, with important nuances for tasks that are not in any project.

This guide explains the key permission behaviors you should plan for when building with Merge + Asana.

Scopes

Merge uses read scope to sync data from Asana.

Permission mapping (how Merge represents Asana access)

Object mapping

Merge maps Asana entities to Merge models like this:

  • Ticket → Asana Task and Subtask

  • Collection → Asana Project and Section

    • Sections are groupings of tasks within a Project.

  • Role → Asana workspace roles (modeled as Admin, Member, Guest) when permissions are enabled.

How Asana access works (high-level)

In Asana:

  • A Task can be part of one or more Projects, or exist independently (project-less).

  • If a user can access a Project, they can access its Sections and Tasks in that Project.

  • Guests typically need to be explicitly added (to the Project and or as a Task collaborator) to gain access.

  • Anyone who can access a Task can access its Subtasks.

  • Important limitation: Asana’s API does not expose a Task’s privacy setting for project-less tasks, so you cannot reliably determine whether a project-less task is visible to all workspace members.

Merge’s permission behavior

Implementation details that affect your product:

Permission effects you will see

Merge represents access using Permission objects that may have one of these behaviors:

  • ALLOWED: direct access is granted to roles, teams, or users.

  • INHERITED: access is inherited from another Collection (used for Sections inheriting from Projects, and Tasks inheriting from Projects).

How Merge builds permissions

Merge builds view permissions using these inputs:

  • Workspace-level roles (Admin, Member, Guest), when applicable

  • Project membership (Teams and Users)

  • Task-level collaborators (assignee + collaborators)

  • Inheritance chains:

    • Section → inherits from Project

    • Task → can inherit from one or more Projects it belongs to

Permissions by Asana entity type

Projects (Collections)

Project shared with entire Organization (or broadly shared)

Merge represents access with up to three grants:

  1. Admin and Member roles

  • effect = ALLOWED

  • applied_to_roles = [Admin, Member]

  1. Teams added as Project members

  • effect = ALLOWED

  • applied_to_teams = [Team(s) that are members of the Project]

  1. Users added as Project members

  • effect = ALLOWED

  • applied_to_users = [User(s) that are members of the Project]

Practical takeaway:

  • Project access can come from role-based access, team membership, and explicit user membership.

Project private to members

Merge represents access only through project membership:

  • Teams that are Project members:

    • effect = ALLOWED

    • applied_to_teams = [Project member teams]

  • Users that are Project members:

    • effect = ALLOWED

    • applied_to_users = [Project member users]

Practical takeaway:

  • Role-based access does not apply for a project that is private to members.

Sections (Collections)

A Section is always inside a Project and cannot have its own access rules. Merge represents this as inheritance:

  • effect = INHERITED

  • applied_to_collections = [Project Collection containing the Section]

Practical takeaway:

  • If a user can see the Project, they can see all its Sections.

Tasks (Tickets)

Task associated with a Project

Merge represents access using two components:

  1. Task assignee and collaborators

  • effect = ALLOWED

  • applied_to_users = [assignee + collaborators]

  1. Inheritance from Project(s) containing the Task

  • effect = INHERITED

  • applied_to_collections = [Project Collection(s) the Task belongs to]

Practical takeaways:

  • A task can inherit from multiple projects if it is added to multiple projects.

  • Collaborator access is additive to project-based access.

Task not associated with any Project (project-less)

Merge represents access via Task collaborators only:

  • effect = ALLOWED

  • applied_to_users = [assignee + collaborators]

Important limitation:

  • Asana has “project-less” tasks that may be visible broadly in a workspace, but Asana’s API does not expose a Task privacy setting. As a result, Merge cannot reliably indicate whether a project-less task is visible to all workspace members.

Subtasks (Tickets)

Asana subtasks inherit visibility from their parent task (“anyone who can access a task can access its subtasks”).

Current important limitation:

  • Subtasks can exist without projects or collaborators, and the current approach does not fully support permission inheritance from a parent Ticket in all cases. As a result, you may not see complete ACL coverage for subtasks in every scenario.

Common scenarios to plan for

“Why can a user see a task even if they are not a project member?”

They may be a Task collaborator or assignee. Merge represents collaborator access with an ALLOWED permission applied directly to users.

“Why can’t we tell whether a project-less task is public to the workspace?”

Because Asana’s API does not expose a Task privacy setting for project-less tasks, so ACLs cannot be fully determined for that case.

“Why does a project look private even when shared broadly?”

Asana’s project.privacy_setting has nuances depending on whether the container is an Organization vs a Workspace; in some cases it can appear as private even when shared broadly in a workspace context.