Portfolio, projects and teams setup : client versus internal topic

English Forum Ask the Community
, ,
1

Hello there :unicorn:

I was reading this previous exchange Using Portfolios to Manage Client Projects Where some are Private & others are Client Facing - #4 by Rashad_Issa and I was wondering how do you manage your internal versus your client / external projects ?

The use of portfolios is pretty obvious and very convenient, but in parallel do you create a new team each time you have a new client ? So all your new project are specific for each client team ?

I was wondering if it is the best practice over time and if not why. And once you have “inactive” client, what are you doing with the team object ? So they do not appear anymore on the active list of team you want to use on Asana.

Thank you very much for sharing your practice and tips :folded_hands:

Have a great day :waving_hand:

1 Like
2

Hey there, great question — this is a super common setup puzzle when working with clients and internal work side by side. I work at Asana, happy to share what I’ve seen work well.

A few patterns that scale

  1. One team per client: Best when each client has multiple projects, unique members, and different permissions. Keeps things tidy if the engagement is big and ongoing.

  2. One “Clients” team with one project per client: Great for lighter engagements where each client only needs a single project and you want a short, clean team list.

  3. Hybrid approach: Keep an internal team with an internal project. Create a client-facing project shared with the client. Use multihoming so tasks that should stay internal live only in the internal project, while client-facing tasks live in the shared project. +1 to the suggestion here: https://forum.asana.com/t/using-portfolios-to-manage-client-projects-where-some-are-private-others-are-client-facing/139722/4

How I handle active vs inactive

  1. Use Portfolios for visibility. Create “Active Clients” and “Archived Clients” portfolios. Move client projects between them as status changes.

  2. Archive projects when a client is inactive. This removes them from day-to-day views but keeps the history.

  3. If you used one team per client and want to keep the team list clean:

  4. Set the team to Private or Request to join

  5. Remove members who don’t need access

  6. Optionally rename to “ZZ Client - Archived” to push it to the bottom of alphabetical lists

  7. Team sidebar clutter usually comes from membership, so leaving teams you don’t need will declutter your view

Permissions tips that help

  1. Share only the client-facing project with the client. Keep your internal project private to your team. Multihome tasks that need dual visibility.

  2. Guests only see what you share with them, so you can keep broader structure internal.

Operational tips

  1. Create a client project template with your standard sections, custom fields, and rules so every new client starts consistent.

  2. Add a “Client” custom field and a “Client Status” field (Active or Inactive) to help with reporting and quick filtering.

3 Likes
3

great suggestions @Stefan_Kirilov

1 Like
4

Hello Stefan,

“Common puzzle” is definitely the right term! Thanks a lot for this awesome feedback. The approach of having one team per client works well, and since we don’t have direct clients in our Asana setup, it’s actually quite easy to manage that way.

For active vs. inactive clients, I follow a similar logic. Instead of using two separate portfolios, I’m using a custom field within a single portfolio. But once the number of clients grows, I’ll probably switch to your solution with two distinct portfolios. Archiving inactive client projects makes perfect sense, I’m doing the same.

I hadn’t considered the team settings themselves, though. It’s great that this setup ensures all members only have access to the active team, and so goes for the projects as well. No more access to previous / archived projects. So just to confirm: does this mean only the administrator can always see all teams that were ever created? Since each team needs at least one member. And of course, we never delete a team, right? Otherwise we would risk impacting the projects linked to it?

Thank you very much for your input!

2 Likes
5

Terrific list of helpful approaches, @Stefan_Kirilov!!

Thanks,

Larry