Show child Building Blocks when viewing a parent Building Block (Panel & Public API) | Feature Requests

Show child Building Blocks when viewing a parent Building Block (Panel & Public API)

Andreas Grub

When working with parent/child Building Block relationships (e.g. a VNet parent with Subnet children), meshStack currently only surfaces the

parent

side of the relationship:

The
Public API
exposes
parentBuildingBlocks
on a child BB, allowing child→parent navigation — but there is
no reverse link
: you cannot query which Building Blocks are children of a given parent.
The
meshPanel
(UI) has the same gap: when viewing a parent Building Block instance, there is no list or indicator showing its child instances.

What we are asking for:

Panel/UI:
When viewing a parent Building Block instance, show a "Child Building Blocks" section listing all dependent child instances (with links). This helps platform engineers and application teams quickly understand the full dependency tree — e.g. "which Subnets belong to this VNet?"
Public API:
Add child navigation support — either a
childBuildingBlocks
field on the Building Block resource, or a query/filter parameter on the List Building Blocks endpoint (e.g.
?parentBuildingBlockId=<id>
) to efficiently retrieve all children of a given parent without having to fetch all BBs and filter client-side.

Why it matters:

Complex automation use cases (e.g. Azure DevOps Pipelines, AWS Step Functions) need to enumerate all child BBs of a parent to collect outputs (e.g. CIDR blocks of all Subnet BBs under a VNet) for downstream operations like firewall rule updates.
The current workaround — listing all Building Blocks in a tenant and filtering by
parentBuildingBlocks
— is inefficient and error-prone at scale.
From a user experience standpoint, understanding which child BBs belong to a parent is also a day-to-day panel use case for operators managing complex landing zones.

"Create a dependent building block on the fly" (open, 9 votes) — related but focuses on ordering child BBs; not a duplicate.

May 7, 2026

Janny the AI Product Manager

Thanks for the super clear write-up — the parent→child visibility gap you’re describing (both in meshPanel and the Public API) makes a lot of sense, especially for dependency-heavy setups like VNet/Subnet.
We’ll share this with the product team. A couple quick questions to help us shape the best approach:
1) In the UI, would you expect the “Child Building Blocks” list to include only direct children, or also nested descendants (a full tree)?
2) For the API, would a filter like ?parentBuildingBlockId=<id>
 be sufficient for your automation, or do you also need to filter by relationship type / Building Block definition (e.g., only Subnets under a VNet)?
3) Roughly how many child BBs can a single parent have in your larger tenants (tens, hundreds, thousands)? This helps us think about pagination/performance.
If you can share an example of your BB definitions/relationships (even anonymized) or a screenshot of where you’d want this in the panel, that’d be really helpful too.

Thomas Abbe

Janny the AI Product Manager

We are currently evaluating how to implement the 1:n relationship between VNet/VPC and subnets. One idea (out of others) was to use these sort of child building blocks.

A list with direct children would be - imho - sufficient, if you could navigate directly to the child building block.
If I understand the docs right, one could combine parentBuildingBlockId=<id>&definitionUuid=<uuid> to get all subnets for a specific vnet?

Especially in the network case, there could be other building blocks which depend on a vpc/vnet, so the combined filtering would make sense.

good questions. For subnets I will bet ten. For other usecases difficult to say.

Thank you