Skip to main content
Solved

Airtable Portfolio/Program/Project Hierarchy

  • September 28, 2026
  • 4 replies
  • 47 views
Forum|alt.badge.img+1

I have been struggling for two weeks to set up a portfolio of projects in Airtable. I have a product that has multiple features. Those features have several projects each.

I’ve completed all the training videos. None of them addressed this. I attempted to use the Project Portfolio Management template but it seems to be driven by the project goals which aren’t important for my team as we are not the product/project owners so have no need to track. 

I also don’t need to track at the task level--just the overall projects status, when sign-off and hand-off occur and, if possible, the status of Jira stories associated w/ each.

 

Read an Airtable article regarding one or multiple bases. Didn’t really get me any closer.

 

Any recommendations on how I should proceed?

Best answer by bredah

You can definitely create the parent-child hierarchy within a single base! I’d actually recommend not creating a separate table for each feature. 

Even with only one product, I’d still structure it as three tables: Products → Features → Projects/Initiatives

Your Product table might only have one record today, but it gives you a clean top level for the hierarchy (and leaves room if you ever do add another product down the line). That Product record would link to its multiple Features, and then each Feature would link to its multiple Projects/Initiatives.

The Linked record fields between those tables are what create the relationships. Then, if you want to actually see everything in a parent-child format, a List view works really well for this.

I’d create the List view from your Projects/Initiatives table. When you set the levels, you can use those linked record relationships to display something like:

Product
→ Feature
→ → Project/Initiative

That gives you a nested, collapsible portfolio view without needing to track tasks or create a separate table for every feature.

Since your pod-level teams are handling the day-to-day project/task work elsewhere, your Projects table can stay focused just on the portfolio-level information you care about: overall status, sign-off/handoff, Jira references, etc. 

    4 replies

    TheTimeSavingCo
    Forum|alt.badge.img+32

    Hm, could you talk a bit more about your workflow?  How the base is set up is going to be heavily influenced by how the data flows and knowing more would be helpful!

    I also do free half hour calls where we’d do a screenshare and cobuilding session too, and you can grab a time here if that sounds useful!

    Adam, Airtable Consultant - https://thetimesaving.company
    bredah
    Forum|alt.badge.img+10
    • bredah
    • Inspiring
    • September 29, 2026

    Hey Hunter! Just based on what you shared, a single base with three linked tables — Products, Features, and Projects — seems like the cleanest way to get that 1:M hierarchy. Then, consider what key fields you need at each level. Since you don't need task-level tracking, you can keep each table streamlined around high-level fields (e.g., status, sign-off dates, hand-off owners, and linked Jira story keys). If you’d like to share a bit more detail about your daily workflow, I’m happy to advise further!

    Hannah
    Forum|alt.badge.img+1
    • Hunter
    • Author
    • New Participant
    • September 29, 2026

    Thanks Hannah, Create one base--understood. However, I have only one product that has several features. Each of those features have multiple projects/initiatives. For clarity, I can’t list them in parent-child hierarchy using that one base, correct? Could I do one table for each feature and list the projects on that table?

    I’m building a project portfolio. Not working at the daily workflow/project task levels--that happens at the pod level. 

    bredah
    Forum|alt.badge.img+10
    • bredah
    • Inspiring
    • Answer
    • September 29, 2026

    You can definitely create the parent-child hierarchy within a single base! I’d actually recommend not creating a separate table for each feature. 

    Even with only one product, I’d still structure it as three tables: Products → Features → Projects/Initiatives

    Your Product table might only have one record today, but it gives you a clean top level for the hierarchy (and leaves room if you ever do add another product down the line). That Product record would link to its multiple Features, and then each Feature would link to its multiple Projects/Initiatives.

    The Linked record fields between those tables are what create the relationships. Then, if you want to actually see everything in a parent-child format, a List view works really well for this.

    I’d create the List view from your Projects/Initiatives table. When you set the levels, you can use those linked record relationships to display something like:

    Product
    → Feature
    → → Project/Initiative

    That gives you a nested, collapsible portfolio view without needing to track tasks or create a separate table for every feature.

    Since your pod-level teams are handling the day-to-day project/task work elsewhere, your Projects table can stay focused just on the portfolio-level information you care about: overall status, sign-off/handoff, Jira references, etc. 

    Hannah
      Terms & ConditionsAccessibility statement