Feature Requests

As a Platform Team of one department (Platform on Platform), I want all cloud accounts belonging to the same department to be able to have a mandatory building block configured into the landing zone, depending on a tag, so that department-specific compliance/governance requirements are automatically and consistently enforced across all relevant accounts without manual intervention. We do not want to create a specific Landing Zone for this, since the complexity with additional Landing Zones would in our opinion increase the complexity. The actual proposal would be a policy condition in the Landing Zone if the building block is mandatory or not.

Problem / Use Case When booking a service from the marketplace, selecting a plan requires clicking precisely on a small, light gray radio button. The radio button lacks a hover effect and has low contrast against the white background, making it difficult to discover and use. Proposed Solution Make the entire plan row/card clickable to select it, and add a visible hover state on the plan card so users can easily identify it as an interactive element.

As an owner of the meshStack platform I would love to have the marketplace more oriented around what's most popular and what not. At the moment the list is just sorted A->Z. It would be great if this was sorted by most popular services as the chance is highest that someone wants to book one of these popular services. On top of that, it would also be cool to show how popular a services is. Similarly to the App Store on your phone, you could see "This service is used in 500+ projects"

Problem / Use Case When a project has a high number of building blocks (16+ is not uncommon in production platforms), the Workspace Overview becomes very hard to navigate. Each building block is rendered as a large card, so users must scroll extensively just to reach the next project. Finding a specific project in a workspace with many BBs per project is slow and frustrating. This became more visible after the new Workspace Overview was rolled out as the default experience (see https://feedback.meshcloud.io/feature-requests/p/show-all-objects-in-workspace-overview ). Proposed Solution Reduce the vertical space consumed by building blocks on a project card in the Workspace Overview. Possible approaches include: A compact list or gallery view toggle for building blocks within a project card A "show more / show less" reveal button that collapses BBs beyond a threshold (e.g., show first 3, collapse the rest) A configurable default display density option

I have a Terraform resource in SAP BTP ( https://registry.terraform.io/providers/SAP/btp/latest/docs/resources/subaccount_entitlement ) that has an optional amount field. I'd like to ask this to my users but also let them skip it if they want to.

Problem / Use Case When a tenant replication is still running and encounters a transient error (e.g. a failed pre-replication check), the UI immediately surfaces a misleading error banner — including confusing messages like "Http failure response: 500 OK" — even though replication eventually succeeds on retry. This creates unnecessary alarm: users (and even operators) assume something is critically broken, open support tickets, and escalate — when the replication was already recovering in the background. Proposed Solution The UI should better distinguish transient in-progress states from real terminal failures: Show a neutral "replication in progress" indicator rather than an error banner when a retry is still ongoing Only surface error details (with the actual failure message) once replication has definitively failed Suppress or downgrade HTTP-level noise ("500 OK") that is not meaningful to end users

we are deploying our building block definitions via terraform. the order in which inputs are defined in terraform is not respected deployed building block definition. this is currently only supported in the UI and not exposed via the public API but i would like the full building block definition state to be inside terraform.

Description: As a platform operator, I want the prerun_script to stream its console output in real-time and immediately terminate if the run is aborted, so that I have full visibility into the pre-run phase. Log Streaming Gap: console output from the prerun_script is only displayed at the very end of its execution, rather than streamed progressively (unlike the apply step). no real-time feedback, operators cannot tell if a script is actively running or completely frozen. Abort BB run Gap: triggering an "Abort" action on a Building Block (BB) run fails to kill the underlying prerun_script process. aborted BB run caused prerun_script process continued running in the background for 3 hours before finally hitting a timeout. The run itself remained trapped in an In Progress state. Proposed Solution: Progressive Logging: Refactor the prerun_script execution block to stream logs progressively to the UI in real-time, matching the behavior of the apply step. State Resolution: Once aborted, the run status should cleanly transition out of In Progress to Aborted or Failed, rather than hanging.

In the "General" tab of the BB definition you can only select platform types for the supported platforms even though the header "supported platforms" suggests, that you should be able to select individual platforms. This is at the very least misleading. We would like to be able to select the platform instead of the platform type here.

Currently, the "Test & Deploy" workflow in the platform builder cannot be used for landing zone-only building block definitions (BBDs), because such building blocks must always be connected to a landing zone. This creates a gap in the onboarding and development workflow for platform builders. Current behavior: Landing zone-only BBDs cannot be tested via the "Test & Deploy" workflow, since a building block of this type can only be configured and instantiated during tenant creation (not standalone). There is no easy way to create a building block instance based on a landing zone-only BBD outside of that tenant creation flow.