Portfolios
A portfolio is for the people who need to look across several projects at once. The rollup container above projects, with team-based access and a privacy switch.
A portfolio is for the people who need to look across several projects at once. A leader running three teams, a PM holding a quarterly roadmap that spans four products, a CEO who wants to see all the in-flight initiatives across the company. The portfolio is the rollup container above projects, and the hierarchy is one level: workspace → portfolios → projects. A portfolio does not contain other portfolios; that's a deliberate choice, since a multi-level rollup tends to collapse into either a tag system or a folder system, and neither is what you want when the records are work.
If you only run one team, you probably do not need portfolios. If you run several, a portfolio per executive sponsor, per product line, or per fiscal quarter is a common shape.
How a portfolio sits in the work model
A portfolio is a rollup. It does not own work directly; it groups projects that live in their own access and reality, and it grants access to its own record through linked teams. Here is the shape of those relationships in one picture.
How it looks in practice
Continuing the worked example.
Marcus Reed is VP of Product. He runs three teams (Analytics, Onboarding, Billing) and needs to see what each team is shipping in Q4 without opening every project. He creates a portfolio.
| Field | Value |
|---|---|
| Name | Q4 Launches |
| Description | All customer-facing launches scheduled for Q4. |
| Owner | Marcus Reed |
| Privacy | Private |
| Status | Active |
| Color and icon | Amber / rocket_launch |
Now look at how the portfolio connects.
Membership. Marcus links three teams to the portfolio from its Teams tab: the Analytics team, the Onboarding team, and the Billing team. The deduped union of those three teams' members (18 people in total, plus Marcus as owner) can now read the portfolio. When a teammate joins one of those teams next quarter, they get portfolio access automatically; when one leaves, they lose it.
Projects in the rollup. Marcus adds three projects from the Projects tab: Sarah's Insights project, the Onboarding Revamp project (owned by the Onboarding team lead), and the Billing Migration project. Each is an independently-owned project with its own membership; adding them to Q4 Launches does not grant Marcus or his portfolio-team members access to the projects themselves. Marcus can see the portfolio's rollups (project counts, status counts, member counts) on the Overview tab; if he wants to drill into a project, he needs project-level access through the team that owns it.
Rollup at a glance. On the Portfolios index, the row for Q4 Launches shows: 3 projects (3 active, 0 paused, 0 completed), 18 members, status Active. On the portfolio's Overview tab he sees the same counts plus the cross-project timeline filtered to these three projects.
Goals supporting the portfolio. A workspace OKR named "Ship 5 customer-facing launches in Q4" has three key results, each pointing at an initiative inside one of the portfolio's projects. The portfolio also carries a "supporting" link from a fourth key result that the leadership team is tracking against the portfolio as a whole. None of these links grant access; they just appear on the portfolio's Overview as chips so a viewer can navigate to the connected work.
Common portfolio shapes
Pick the shape that matches the question you keep getting asked.
Per executive sponsor. One portfolio per VP or director. The portfolio groups the projects each leader is accountable for. Useful when leadership-review-quarterly is the conversation that needs an at-a-glance answer.
Per product line. One portfolio per shipped product. The portfolio groups the projects (often per team) that build the product. Useful when "where are we across this product" is the conversation.
Per fiscal quarter or planning cycle. One portfolio per quarter or per planning round. Projects come in and out of the portfolio as they get scoped for that cycle. Useful when "what are we doing this quarter" is the question.
A company-wide rollup. One portfolio that holds every active project. Useful for the CEO or the chief of staff who wants the whole picture.
These are not mutually exclusive. A project can be in several portfolios at once, so the same project under "Acme team" can also appear under "Q3 launches" and "Enterprise product." Each portfolio is its own perspective on the same underlying work.
Two surfaces called "Portfolio"
A naming knot to clear up before we go further.
The Portfolio dashboard (singular, at /planning) is the workspace landing page. It shows pinned projects, the cross-project timeline, workspace-wide goals, and quick-create actions. It is the first screen a user sees when they open the product. This page does not hold a portfolio record; it is a workspace dashboard.
The Portfolios index (plural, at /planning/portfolios) is the list of portfolio records. Each portfolio in the list is a real record you can create, edit, delete, and grant access to. The detail page of a portfolio at /planning/portfolios/:id is what the rest of this guide is about.
A naming cleanup between the two is on the backlog. Until then, the singular "Portfolio" in the side rail is the dashboard, and "Portfolios" plural is the entity.
When you create one
Click into Portfolios from the side rail and click New portfolio. The only required field is a name, which has to be unique within your workspace. The other fields at creation are description, color, icon, and the privacy setting (more on that below).
The portfolio defaults to private privacy and active status. You become the owner. The owner has full access regardless of any other membership.
Statuses
Two:
- Active is where a portfolio sits while it's a working rollup.
- Archived is a soft hide for rollups you want to retire without deleting.
Portfolios are rollup containers that change over time rather than work units that finish, so there is no "completed" or "done" status to mark; a portfolio whose projects have all wrapped up just gets archived. Archiving leaves the portfolio in the system, hides it from default lists, and does not affect the projects underneath. Status transitions are free; move between active and archived as you need.
Soft-delete and the trash view
Soft-delete is a separate concern from status. A deleted portfolio is excluded from the default Portfolios list; the rollups computed on the list page also exclude it.
To reach the trash, open the Portfolios list and click the Trash toggle in the toolbar. The list switches to deleted-only mode; each row carries a "Deleted" badge and an updated row-action menu with Restore and Delete permanently instead of the normal edit actions.
Restoring is a one-click move (a confirmation dialog asks first); the portfolio comes back active with all its team links, project links, and key-result links intact, so a restored portfolio lands back exactly where it was.
Hard-deleting and the link cascade
Hard-deleting a portfolio is only allowed from the trash view (you have to soft-delete first), and the cleanup cascades through three sets of links in order:
- Key-result links pointing at the portfolio (these become orphaned chips on the goals that referenced it)
- Team links granting access (these leave the team alone)
- Portfolio-to-project links (these leave the projects alone)
The portfolio row itself is the last thing to go. None of the linked records (goals, teams, projects) are affected; only the connections between them and the portfolio are.
Privacy
The privacy setting is the part most worth understanding before you create a portfolio. A portfolio carries one of two values.
Private (the default)
Only the owner and members of any team linked to the portfolio can read it. Everyone else does not see it in their list and gets a 404 if they try to open it directly. This is the right default for most uses.
Public
Anyone in your workspace can read it. Public portfolios can also be edited by anyone in the workspace; the privacy setting governs both read and write. A team rolling up shared metrics for a workspace-wide objective might pick public; a leadership rollup across confidential projects would stay private.
Admins read every portfolio but cannot edit every one
A workspace admin's portfolio-manage scope grants admin-bypass on reads but not on writes. To write a portfolio you have to be the owner, a member of a linked team, or operating on a public portfolio. This is deliberate; admins should not be able to silently edit a leader's rollup without being on the team that owns it.
Privacy is for the portfolio record, not the projects within
The privacy setting governs the portfolio record itself. Projects keep their own access model regardless of which portfolios they roll up to; a private portfolio does not hide its public projects, and a public portfolio does not unlock its private projects. This is why the portfolio is described throughout this guide as a rollup rather than a container: a container would imply that access flows down, and on a portfolio it does not.
Membership
Portfolios use team-based membership, period. There are no direct portfolio members. To grant someone access to a portfolio, add them to a team and link the team to the portfolio.
Workspace admins manage who's in which team in Settings → Teams.
From the portfolio's Teams tab. One click per team.
Add or remove people from the team and portfolio access tracks automatically.
This keeps the model simple. One place to manage access (the team), one link to make (team → portfolio), no per-portfolio member lists to maintain. It also means a portfolio's access naturally follows the team's evolution; people who join the team get access, people who leave lose it.
The owner is the exception. The portfolio's owner is always counted as a member regardless of team links; otherwise the creator could lock themselves out of a portfolio they just made.
A team is linked from either side, depending on where you are when the need comes up:
- From the portfolio's Teams tab. Click Link a team, pick the team from the dropdown, confirm. The team's name appears in the Linked Teams table immediately and its members get read access on their next page load.
- From the team's detail page (Settings → Teams → the team). Click Link to a portfolio, pick the portfolio from the dropdown, confirm. The same link gets created; the portfolio's Teams tab updates the next time it loads.
Both paths end up in the same place; pick whichever surface you're already on. Unlinking works the same way on either side: a row's Unlink action drops the link without touching the team or the portfolio.
Portfolios and projects
A portfolio holds projects in a many-to-many relationship. A project can be in several portfolios; a portfolio can contain many projects. The portfolio's Projects tab is where you add or remove the links.
Adding a project to a portfolio does not grant anyone access to that project. The portfolio is a rollup convenience. Project access is governed by the project's own membership (the four-branch model on the Projects page); adding the project to a portfolio does not change who can see or edit the project.
The same goes the other way: a portfolio member does not get access to the projects in the portfolio. They see the portfolio rollups (project counts, status counts) without seeing the individual records they do not have access to. This is the right behavior for a leader's rollup of cross-cutting work: the leader sees the shape of the portfolio without inheriting access to every project's day-to-day records.
The detail page
Four tabs.
Overview carries the description, the privacy and status, the key results pointing at the portfolio, and the high-level rollups.
Projects lists the projects in the portfolio. Add and remove links from here.
Teams lists the teams linked to the portfolio. Add and remove links from here. This is where membership is actually managed.
Settings holds name, description, color, icon, the privacy toggle, the status toggle, the soft-delete action, and the hard-delete action (which only appears if the portfolio has been soft-deleted first).
Rollups
A portfolio carries three rollups, computed when you load the list and freshened on every load (not cached). These give a leader the at-a-glance view without having to open each project.
- Project count. How many active projects are in the portfolio. Soft-deleted projects are excluded.
- Member count. The deduped count of users from all teams linked to the portfolio, plus the owner.
- Status counts. A breakdown of project statuses (for example, 2 active, 1 paused, 0 completed).
These show on the Portfolios list and on the portfolio's Overview tab. For the time-axis view of work across the portfolio's projects, the cross-project roadmap on the workspace dashboard is the surface to use; filter it by the projects the portfolio holds to scope the view.
Goals on a portfolio
Goals do not belong to portfolios the way they belong to projects. What can happen is that a key result on a goal points at a portfolio as a target. The portfolio does not drive the key result's progress (only initiative-targeted key results do); the link just lets a viewer see that the portfolio is contributing to the goal.
The Overview tab surfaces these as Connected goals: clickable chips that show the goal's name, a status badge (achieved / on track / at risk / off track / cancelled), and a click-through to the goal's home in its project. The link only navigates if the goal lives inside a project the viewer can access; otherwise the chip renders read-only. This is the right behavior for a leader's rollup: the chip tells you the goal exists, and the click takes you to the work if you have rights to read it.