🕐

Some of you have asked that mandatory LZ Building Blocks should not be deletable by application teams outside of the tenant deletion flow — to avoid tenants entering a state where mandatory building blocks are no longer present.

A related alternative that may address some cases: Building Block Deletion Approval (open, 5 votes) — this would allow platform operators to require approval before a BB is deleted, giving them a chance to intervene and handle any manual cleanup steps.

✅

Tracked separately: Hide building block inputs from end users

Static inputs (credentials, identifiers managed by the platform) are now hidden by default. Users can reveal them via "Show static inputs" but sensitive values remain hidden for everyone. This reduces noise when application teams inspect mandatory building blocks.

🟡

Tracked separately: Allow specifying user inputs for mandatory building blocks via API

Tenants can now be created via the API when mandatory Building Blocks have user inputs . The remaining gap — mandatory BBs with required user inputs that have no default — still blocks full API-driven tenant creation. Feedback on this is welcome on the linked ticket.

We are keeping this request open as some items still have open work. Thank you for all the detailed feedback so far — it directly shapes our roadmap.

This request covers several distinct problems. Here's a breakdown of where each one stands:

✅

Tracked separately: Automatically delete building blocks on tenant/project deletion

Deleting a tenant or project now automatically removes all associated Building Blocks in the correct dependency order. The deletion page gives you a full preview before confirming. This resolves the frustrating blocker where mandatory LZ Building Blocks had to be manually removed before tenant deletion was possible.

✅ (Sep 2025)

There is still an open request for treating mandatory BBs as "Landing Zone inputs" rather than separate building block inputs: Show mandatory / Landing Zone-only building block as Landing Zone inputs (open, 10 votes).

It's worth calling out that building block compositions (ie a building block that provisions a tenant + other building blocks) offers a suitable alternative for such a unified user experience.

(continued in next comment due to character limits)

We have taken some steps here to make this better. I would still leave this feature request open to collect feedback, as there might be some work left before considering it fully done:

One open point is still to delete Building Blocks upon tenant deletion. This is still a bit cumbersome and has to be done manually by the user before they can delete their tenant or project.

This would work for building blocks which do not require any user inputs. It should be considered another feature to "inherit tags from superior project" to make user input obsolete in such scenarios.

As I understood it, the hiding would also make it impossible for a user to remove this building block again on his own, which is also often a requirement for mandatory landing zone based building blocks. I got this as feedback from a customer.

While we currently don’t offer this feature, we are planning on offering it or something similar to it. I can’t give you the exact timeline of when it will be ready, but I can tell you that it’s already planned and we’ll have it released within the next few months.

I just added you to the follow-up list, so as soon as we do have news regarding this feature, we’ll be sure to reach out. Feel free to let us know if you have any other questions or feedback.