[Change] Teamless Projects

[John_Baldo]

Summary

As we continue to evolve how projects are organized in Asana, newly created projects will no longer require a containing team. The project.team field will be null by default for new projects.

To maintain compatibility with existing integrations, you can still associate a team with a project using the project.team field. However, teams are no longer the primary way to organize projects. Going forward, we recommend using portfolios for organizing and managing related projects.

The breaking change: If your application reads project.team, you will need to update your code to handle a null value for this field.

Who is affected

Any application that reads the project.team field from the API. This includes integrations that:

• Organize or categorize projects based on their containing team

• Use project.team to determine project context or routing

• Assume project.team is always a non-null object

Changes by endpoint

Reading projects

All endpoints that return project data may now return null for the team field on newly created projects:

• GET /projects

• GET /projects/{project_gid}

• GET /workspaces/{workspace_gid}/projects

• GET /teams/{team_gid}/projects

Projects created before this change will continue to have their existing team set in project.team. Projects created after this change will have team: null by default unless a team is explicitly specified at creation.

Example response for a new project:

{
    "data": {
        "gid": "12345",
        "name": "Project Name",
        "resource_type": "project",
        "team": null,
        "privacy_setting": "public"
    }
}

Creating and updating projects

The team field remains fully supported on project creation and update endpoints. You can still set a team when creating a project, but it is no longer required.

• POST /projects

• POST /teams/{team_gid}/projects

• PUT /projects/{project_gid}

Migration steps

1. Audit your code for any place you read project.team and assume it is non-null.

2. Add null handling — ensure your application gracefully handles project.team being null.

3. Test your integration against newly created projects once the rollout reaches your workspace.

No changes are needed for applications that write to project.team.

Timeline

• February 2026 - Gradual rollout begins. As this change is enabled in the Asana web app for a workspace, the corresponding API changes will also take effect.

• April 2026 - Rollout complete for all workspaces.

Why we’re making this change

This change gives Asana users more flexibility when creating projects. Teams can still be associated with projects as needed, but they are no longer a prerequisite.

This also simplifies the creation of private projects intended to be shared only with their direct members.

Questions and feedback

Let us know if you have questions or feedback about this change. We know API changes can be disruptive, and we appreciate your patience as we continue to improve and evolve Asana projects.

---

Edit 1 (Feb 2026): Revised plan based on developer feedback. Team associations remain fully supported via project.team but the field is now optional rather than deprecated. Removed previously announced endpoint deprecations and write restrictions. See this reply for a summary of changes.

[lpb]

Thanks, @John_Baldo, for the good, clear writeup.

So can we expect somewhere around April that you’ll use the opt-in/out headers (sorry, forgot the proper term you use) when rolling all of this out?

Thanks,

Larry

[Phil_Seeman]

I agree with Larry, @John_Baldo - thanks for this very detailed and clear info!

@John_Baldo

To maximize backward compatibility, projects created before this change will continue to return a team gid in the project.team field until that team is no longer a member of the project.

@John_Baldo

GET /teams/{team_gid}/projects
…

• To maximize backwards compatibility, this endpoint will continue to function, but will return the projects where the given team is a member (the same as GET /memberships described above).

@John_Baldo

Setting a team gid on project creation will add that team as a member of the project

I think these are all helpful and thoughtful decisions.

Question:

@John_Baldo

PUT /projects/{project_gid}

• You will no longer be able to update the project.team field over the API.

Will sending the team field cause the PUT call to fail, or it will just ignore anything sent in the team field?

[FreshyJon]

@John_Baldo

In 6 months (roughly April 2024)

I think you mean April 2025

Also, how/when will we be able to specify which team(s) get added to a project created from a Project Template? Within the Project Template interface (UI), there is no way to add team(s) to the project that gets created from the template.

[John_Baldo]

Hey, I want to quickly acknowledge and thank you for the questions. I am working on getting answers which I will post here and update / edit. And thanks for pointing out the typo, @FreshyJon! Hard to believe 2025 is almost upon us.

[John_Baldo]

Hi @lpb @Phil_Seeman @FreshyJon ,

Sorry for the slow reply. I’ve updated the post to clarify:

• We’ll allow an opt-out period (for the API but there still may be a null team value when a project is created in the Asana web app)
• instatiateProject will have the same behavior as POST /projects and I’ve added it to the list.
• Attempting to update the team field with a PUT will return an error.

[Jessica_Reese]

@John_Baldo

instatiateProject

Can you help advise how to correct this now to adhere to the change?

[Peter_den_Hollander]

@John_Baldo or for who is doing a quick text search on ‘duplicate’, how will the team parameter function for:

POST /projects/{project_gid}/duplicate

[Andrew-asana]

Hi everyone, thanks for your continued engagement and thoughtful questions and feedback on this thread.

We previously shared that the rollout of teamless projects would begin around April 2025. While we’re actively making progress, we’re pushing the timeline out slightly to support a smooth experience for all developers and users.

We’re now targeting a release at the end of this fiscal year and will update this thread again as soon as we have a firmer date. In the meantime, project.team will continue to behave as it does today.

We really appreciate your patience and understanding as we take the time to get this right — and as always, please keep the feedback coming!

[Phil_Seeman]

Hi @Andrew-asana,

@Andrew-asana

We’re now targeting a release at the end of this fiscal year

Just to confirm, your current fiscal year ends Jan 31, 2026, so this release will likely be late this calendar year or very early the next one, is that correct?

[John_Baldo]

Updated timeline:

• January 2026 - we will begin gradually rolling out this change and expect the rollout to continue for 2 to 3 months.
• April 2026 - teamless projects rollout completed

As this changed is rolled out in the web app for an Asana workspace, the API changes will also be rolled out.

NOTE: We are removing the ability to opt-out given the amount advance notice and the inability to opt-out of project <> team association once the changes are live in the Asana web app. Creating projects with the project.team field will continue to work successfully, but the field will no longer be required or persist.

[Phil_Seeman]

Hi @John_Baldo,

In the announcement of teamless projects for the web app, there is this:

Preserving historical project–team context

Before teamless projects, every project in Asana lived inside a team. That historical project–team information is not lost with this change.

Asana preserves this data so customers can still understand where a project originally lived under the previous model.

What this means:

• Projects created under the old model keep their historical team context
• You can find this information in Project details, listed as Associated team
• This helps maintain continuity for filtering, reporting, and understanding a project’s background

So the web app will have this concept of “an Associated team”. My question is, is that the API equivalent of the current project.Team property, or ??

[Mikhail_Melikhov]

Thanks for the question @Phil_Seeman . The short answer is: we’re still finalizing the best migration/modeling approach internally, prioritizing preserving backwards compatibility wherever possible.

What is clear now is that project.team will no longer be a reliable field to assume always contains a reference, so API consumers should make sure they gracefully handle it being null.

We’ll communicate the exact semantics for involved endpoints ahead of rollout.

[Phil_Seeman]

@John_Baldo

For existing projects, the containing team (previously set when the project was created) will be migrated to be a member of the project.

Wasn’t this already done last year when the concept of a team being able to be a project member was introduced?

[Phil_Seeman]

@Mikhail_Melikhov @John_Baldo @Melat_Begashaw,

There are a few ways in which the plans for the API listed here seem to me to be inconsistent with the teamless-project changes coming in the web UI.

Overall, IMO the project.Team field should map 100% to the behavior of what will be called the “Associated team” field in the web UI. I see a few ways in which they differ:

@John_Baldo

If the team is removed as a member of the project, the project.team field will become null.

This doesn’t seem right, unless what you mean here is “if the team is removed as the project’s Associated team, the project.team field will become null”?

@John_Baldo

To maximize backwards compatibility, this endpoint will continue to function, but will return the projects where the given team is a member (the same as GET /memberships described above).

It seems to me this should instead operate as “will return the projects where the given team is a project’s Associated team”. That would be the closest backward compatibility.

@John_Baldo

You will no longer be able to update the project.team field over the API.

I think this is the wrong behavior. Since one will still be able to update the Associated team in the web UI, and project.Team corresponds to the Associated team, one should still be able to update that value via the API.

[lpb]

I haven’t looked into this deeply, but everything you propose seems better!

Thanks,

Larry

[Melat_Begashaw]

Hi @Phil_Seeman ,

We’ve heard your feedback about the importance of team-project associations in existing integrations, and we’ve revised our plan accordingly. Here’s a summary of what changed

What’s staying the same:

• Newly created projects will no longer require a team. The project.team field will be null by default on new projects.

• All API clients should be prepared to handle a null value for project.team.

What changed from the original plan:

• Team associations are still supported. You can still set project.team on both create and update. We are not deprecating the ability to associate a team with a project.

• No endpoint deprecations. We are no longer planning to deprecate GET /teams/{team_gid}/projects, and the project creation and update endpoints will continue to support the team field as before.

• No breaking changes to write operations. Setting a team on project creation will continue to work as it does today — the team will be set as the project’s team, not converted to a membership.

The key change for API clients: If you read project.team, your code must now handle a null value, since newly created projects won’t have a team by default. Projects created before the rollout will retain their existing team association.

We’ve updated the original post above to reflect this revised plan. The core timeline remains the same: gradual rollout beginning February 2026, completing by April 2026.

The original post has been updated to reflect these changes.

Thank you for your feedback. We’re committed to evolving the Asana while minimizing disruption to existing integrations.

[Phil_Seeman]

I believe the API has recently changed in a way that was indicated here it would not.

Specifically, this endpoint: /teams/{team_gid}/projects

The above post says:

What changed from the original plan:

• No endpoint deprecations. We are no longer planning to deprecate GET /teams/{team_gid}/projects, and the project creation and update endpoints will continue to support the team field as before.

I interpret that, along with the initial post here, to mean that the above endpoint to get the projects in a team should have no behavior change from its “pre-teamless-project” behavior.

However, that’s not what I’m finding in my testing just. Here is what I found:

Scenario:
A private project Project X has its team field set to team gid 12345

Expected behavior:

• When calling /teams/12345/projects , Project X will be listed, regardless of whether or not team 12345 is a project member of Project X.

Actual behavior:

• If Project X is private and includes team 12345 as a project member, Project X is listed in a call to /teams/12345/projects
• However, if private Project X DOES NOT include team 12345 as a project member, Project X is NOT listed in a call to /teams/12345/projects.

I believe this is an incorrect change in behavior for that endpoint. (I can demonstrate this in Postman if desired.)

cc: @Melat_Begashaw @John_Baldo

[Melat_Begashaw]

Hi Phil,

You’re correct, this is a bug and the behavior is not what we intended. The plan with Teamless Projects was not to change the behavior of GET /teams/{team_gid}/projects. Private projects that have their team field set to a given team should still be returned by this endpoint, regardless of whether that team is also added as a project member. We are working on a fix right now and you should see it reflected on your end by the end of next week at the latest.

Best,

[Phil_Seeman]

Thanks for confirming, @Melat_Begashaw, and good to know it’ll be fixed in short order!