💡 5 tips and notes on the recent changes to sharing projects with teams

Since the recent launch of team sharing on projects there has been certain confusion raised by some of my customers that I consult as well several members in this forum!

The changes have impacted several aspects of Asana, most notably the data model which previously allowed a project to belong to a single team, now it also allows a project to ‘appear’ in more than one team. This is similar as to how a task can be multi-homed into more than one project! This particular change is great because, previously, teams (that would both work on a single project) would argue over who’s team the project would belong to :sweat_smile: But now, the same project can appear in (and shared with) more than one team!

Let’s deep dive into the changes and understand the differences before and after (now), as well as how we can leverage these changes and what to look out for!

1. Changes to options for sharing a Project

Before:

Previously, we had 3 options for sharing a project:

  • :office: Entire organization
  • :busts_in_silhouette: Team only
  • :lock: Private to members

After:

With this update, we now only have 2 options for sharing a project:

  • :office: Entire organization
  • :lock: Private to members

Note that :busts_in_silhouette: Team only is no longer available. So where did it go?

If your project was previously set to Team only you will now see the Team appear as a member in the options below. That is now the equivalent of sharing the project with your team!

You can now set the project permissions for all the Team members of that Team (as either Project Admins, Editors, Comments or Viewers) as well as set their notifications by clicking on the blue text Manage notifications (as seen above) to set whether they will receive Status updates, Messages or Tasks added:

:bulb: You will likely want to uncheck Tasks added since they can generate many noisy notifications!


2. Sharing projects with multiple teams (making a project appear in more than one team’s list of projects)

Before:

Setting a project to :busts_in_silhouette: Team only was fairly straightforward; the project would appear in the list of projects in the Team’s Overview tab, accessible and viewable by all the Team’s members.

However, if the Team’s privacy settings was set to Public to organization, then everyone in the organization would have access to ALL the projects within that team, unless the projects were set to Private to members.

After:

Now that we can share a project with multiple teams (currently limited to up to 10 teams), it means a project will appear in every Team’s list of projects in that Team’s Overview tab, as well as the equivalent Team’s fly-out menu in the sidebar.

Some customer’s are confused by this change because it is a completely new game-changing ability :star_struck: .

:bulb: Teams no longer need to argue over who’s team the project will appear in - they can now appear in both or many.

Additionally, some customers are reporting they are seeing ‘duplicate projects’ across various teams, trying to delete the one but resulting in deleting both ‘duplicates’ simply because they don’t realise it is actually the same project appearing in more than one team. And in their defence, this is a reasonable assumption since this was not previously possible.

:bulb: Note, when adding more than 20 members within the Team(s) you are inviting, you get the option to notify the +20 members about joining the project, as well as setting whether they will receive status updates and messages.

image

If you have 19 or less members within the teams that you are inviting, you will not get these options, but only whether to notify the members whether tasks are added to the project (which we all know by know, that’s very noisy so we always leave this unchecked!)

image

Once you add all the teams, each team will see the project in the Team’s Overview tab, as well as within the sidebar’s flyout menu.


3. Moving a project to another Team

Before:

Previously, to move a project from one team to another, you would need to be a member of both Teams and simply use the Project Details modal (from the dropdown next to the Project’s title) to change the Team that the project belong to. i.e. in which Team that project would appear in, and therefore have access to.

After:

Now, a project is ‘owned’ by a single team, however, it can now appear in multiple teams (currently limited to 10 teams) as we saw it part 2, above. Therefore, if you now use the Project Details modal (from the dropdown next to the Project’s title) to change the Team that the project is owned by, you will see the following message:

In this example, I changed the Team (that owns the project) from :earth_africa: Field Marketing to :rocket: Product Marketing. Previously, the access to the project would simply be changed over from one Team to another. However, now, the following will happen:

  • Members in the :rocket: Product Marketing can’t access or see the project (yet)
  • Members of the :earth_africa: Field Marketing team can still access and see the project within their team.

This, perhaps unexpected behaviour, is because I need to update the project’s share settings to only the :rocket: Product Marketing which I moved the project to (I could optionally include both teams).

:bulb: Therefore, to ‘truly’ move the project from one Team to another, I would need to invite the ‘destination’ team :rocket: Product Marketing as a member, whilst removing the ‘source’ team :earth_africa: Field Marketing from the members list, as per below.

:bulb: Note, above, we receive a warning that the :rocket: Product Marketing team’s permissions are set to ‘Public to organization’ and therefore anyone can now access the project. To correct this, we would edit the :rocket: Product Marketing team’s permissions and set it to Membership by request or Private.

:bulb: Note, the team that ‘owns’ the project is the Team that appears in the :busts_in_silhouette: Team column in a Portfolio.

This new behaviour can be a bit confusing so you may want to vote here on improving it.


4. Sharing a project with a team, upon creation

Although we now have 2 sharing options, as noted above, we still see all 3 options when we create a new project, either a blank project or from a template, as per below.

Note, :busts_in_silhouette: Shared with team is available as an option, only at this point of creation.

:bulb: Setting to :busts_in_silhouette: Shared with team, will essentially add the team (which we have set under the Select a team dropdown) as the ‘owning’ team but also as a member of the project, setting them as an Editor, by default.


5. Making a project ‘truly’ private

Before:

Setting a project :lock: Private to members was fairly simple; you would essentially add only as members, specific people from your team, providing them access to your project. Only they would see the project appear in the Team’s Overview tab, whereas other Team members would not.

:bulb: You could, and still can, add members from other Teams to your project in order to provide them with access - they will just not see the project in any team.

After:

Now, since we can also add Teams as members to our projects, even though the project access setting is set to :lock: Private to members , we need to remove the Team as a project member in order to make the project truly private to just those members.

In the below example, Maria would need to remove the :earth_africa: Field Marketing team as a member from the project so that it no longer shows up in the Team’s Overview tab or accessible to other Team members. The project will only show up in the Team’s Overview tab for Maria, George and Nick but not to other Team members.

:exclamation: Additionally, Maria would also need to check which Team is the ‘owner’ of the project from the Edit project details modal and make sure it is also set to :earth_africa: Field Marketing. If it was still set to :rocket: Product Marketing (which was a public team), then our ‘private’ project would still be fully accessible by all organization members, even though our Share project modal settings may note otherwise!

Lastly, note that projects set to :lock: Private to members no longer indicate the :lock: icon which was previously clearly visible in the Team’s Overview tab or the fly-out menus of the sidebar. This is unfortunate or perhaps something that will be coming back in a further update. In the meantime, you can vote for it, here.

:rocket: See all of my top tips & tricks on my website.

18 Likes

@Richard_Sather - excellent job on this thorough and very helpful tutorial on how the new setup works. I see a lot of strengths with the new setup, and, like you, hope they make a couple final changes to make it a bit more intuitive. I voted for the improved “moving of projects” experience.

Thanks for putting this together!

2 Likes

Brilliant, @Richard_Sather - everyone needs to bookmark this post!

3 Likes

@Bryan_TeamKickstart , @Phil_Seeman , thanks for your kind words :heart:

It’s a great new feature/ability but indeed, it’s fairly complex and different to what we have grown accustomed to, for years!

1 Like

Great post, @Richard_Sather!

The changes are helpful but, in places confusing, unfortunately.

I previously voted for the additional requests you mentioned and encourage others to do so as well.

Thanks,

Larry

3 Likes

Great post @Richard_Sather thank you for you kind review and comparison!

1 Like

@Richard_Sather this is very useful. I totally understand the confusion especially when trying to make a project totally private, which may now require couple more steps.

1 Like

Awesome post!!! Thank you @Richard_Sather !!

1 Like

@Richard_Sather :clap::clap::clap:

Thank you for explaining it clearly. It really helps to have this post to point to.

1 Like

Thanks everyone! Glad you find this post useful. I also use it to point my clients to it as well as users here in the forum :slight_smile:

1 Like

I’m back from holidays still troubled by this topic :sweat_smile: and Boom this clarifies everything, awesome job @Richard_Sather :muscle:

2 Likes