Globally-Accessible Projects Available to Entire Organization

Currently, a public team can create public projects, but there’s no way to make those available to our entire organization (ie, across all teams), without manually adding each individual employee. You would also have to add new hires, going forward. This is true in practice, and also checks out based on this guide article:

Technically, only Team Members can access a Public Team’s public projects and Team Conversations.

It would be really valuable to have a “global” permission option on projects, which would allow individuals to contribute toward a project without having to join the team. For example, we have a Bug Reports project within our Technology team. It doesn’t make sense for a member of our Education team to join the Technology team, but they frequently need to report bugs.

TL;DR - Globally-accessible projects would allow us to retain a logical structure and team ownership of a project, while granting automatic task-management capabilities to all organization members.

2 Likes

@Casey_Dwyer great suggestion I have upvoted it. Make sure you do the same…

Jason…

2 Likes

Actually this is usually solved by having a main team for every employee, where you can host company-wide projects. Allows you to use the Message feature at the team level as well, pushing announcements to everyone.

2 Likes

Heh, yeah we actually used to have one of those!

Removed it a couple of years back, however, because it got messy and project ownership wasn’t clear. It also doesn’t address the issue of having to manually add users to an additional team (ie, besides their primary/actual departmental team).

I have upvoted the feature as well, but we also use the global team which is open for everyone to access and then have specific teams. This is something we use not only for asana, but for other tools we have in place as well.

Had a minor revelation today; realized we could potentially use Zapier + the Asana API to accomplish this by assigning any/all “global” projects (that we pre-define & manage within the Zap) whenever a new user is created. After digging into it, we are frustratingly close, haha.

There’s an available trigger in Zapier for a New User, which works well. Then on the action side, we set up a manual POST webhook to hit this Add Users to Project endpoint. Which sounds perfect! Except that the endpoint is nerfed to a degree, since both the Permission (edit vs. comment) and Notification (new task) settings are not included/available as query params for that endpoint. The docs actually address the latter, mentioning how the user’s defaults will override the default behavior.

If I’m missing something obvious, would love to be enlightened! Otherwise, I’m curious if anyone on this thread could possibly help elevate this to get it on the radar of the Asana team responsible for API design? Would love to get some opinions on this, and potentially see this functionality added at some point in the future, if it makes sense and isn’t too technically challenging. :crossed_fingers:

Below is a screenshot of what the GUI equivalent looks like, within Asana itself. TL;DR - Essentially would like to have access to the two highlighted bits via the API.

@Casey_Dwyer,

I think perhaps the best approach would be to create a new topic in Developers & API (which developers will see), make it specific to the API changes you’re requesting, and include a pointer to this thread.

Thanks,

Larry

Good call Larry, thanks for the suggestion—I will do that!

1 Like

The permission/membership API is about to drastically change and be improved so I believe you might benefit from this work. Right @Phil_Seeman ?

Right! I’m going to reply further in the other post on this topic in the API forum section.

1 Like