Feature Requests

## Summary Introduce Platform Views in meshStack: customizable, focused views that represent a complete internal platform (e.g., an IDP, AI Platform, Data Platform, IoT Platform) as a coherent product , not as scattered Building Blocks and services in the general marketplace. Platform Views help users understand “which services belong to my platform?” and help platform teams present, curate, and evolve their internal platform offerings in a single place. Please note that this is a proposal meant as an impulse to inspire discussion and not a definitive finalized description of the solution. So your feedback is very welcome! I make this request detailed nevertheless to make it more tangible. ## Problem meshStack allows organizations to build internal platforms from many components: * Building Blocks * Landing Zones * Projects * meshPlatforms * Documentation, policies, support channels, etc. Today, these appear separately in the marketplace and UI. This causes: Users struggle to see which services belong to a given platform → Cognitive overload, unclear onboarding. Platform teams cannot present their platform as one coherent experience → Components feel fragmented, even when dependencies exist. meshStack demos cannot easily show “how internal platforms are built” → The value of platform composition stays conceptual. In short: Users want platforms. We currently show components. ## Proposal: Platform Views Introduce a new first-class meshStack object: Platform View . A Platform View is a curated, tag-driven, dynamic collection of everything belonging to an internal platform. ### A Platform View may include: * Filtered Building Blocks (by tag or manual inclusion) * Filtered Landing Zones * Related Projects / Workspaces (optional) * Platform README * Documentation links * Policies / guardrails (where supported) * Support channels / contacts * Getting-started steps * Optional: playgrounds or sample stacks ### How it works A platform team creates a Platform View with a name (e.g., Web App Developer Platform , AI Research Platform , Data Analytics Platform ). They define tag filters (e.g., platform:webapp ) or manually add components. meshStack automatically displays all matching services/BBs, including future ones. Users can subscribe to a Platform View: * Receive updates when new capabilities arrive * Become visible as subscribers to the platform team * Enable later interaction and feedback loops ## Why this matters ### For Users One place to see everything* needed for a specific platform * No more guessing which components belong together * Clear onboarding and faster success ### For Platform Teams * Present the platform as a product, not a loose set of services * One home for docs, support, usage guidance and architecture * Visibility into adoption through subscriptions ### For Organizations * Enables a discoverable catalogue of internal platforms (IDP, Data, AI, IoT…) * Supports platform federation and modular composition across teams * Makes platform engineering outcomes visible and reusable ### For meshStack * “Show, don’t tell”: demos become dramatically clearer * Strengthens positioning as a Platform Builder * Highlights a strong capability: dynamic platform definition from a shared service pool ## Potential Future Add-ons (not required for initial MVP) * Platform Analytics: usage, adoption and maturity per Platform View * Platform Maturity Levels: optional completeness/compliance indicators * Platform Collaboration: feedback from subscribers to platform teams * Access Modes: optional “platform lock mode” to restrict users to specific curated scopes (e.g. useful for multi-tenancy or "single platform" users) * Integration with Platform Builder: blueprint visibility inside the Platform View ## Why now Organizations increasingly operate multiple internal platforms—not just one IDP. Without a unified presentation layer, users experience meshStack as a collection of services rather than a true platform ecosystem . With Platform Builder, we capture the Platform Team perspective, but a corresponding user perspective is currently missing. Platform Views make internal platforms discoverable, understandable, consumable, and evolvable inside meshStack. ## Request Please consider adding Platform Views as a first-class meshStack feature to: * Clarify internal platforms for end users * Reduce user confusion and cognitive load * Enable platform teams to package their work as a product * Make meshStack’s platform-composition capabilities visible to improve demos and customer adoption

As a Platform Operator, I would like to have the option for a deletion approval when a user deletes a building block. This would be useful in cases where there are manual steps involved after deleting the building block. Similar to the process of platform operator inputs.

As a Platform Engineer I want safety mechanisms regarding the dependencies between Building Block during the upgrade of buidling block definitions. If a Building Block is upgrade to a new released version other building blocks with a dependency might be re-run with unexpected results. Therefore a warning before upgradeing Building Blocks should be displayed with information about: which building block definitions has a dependency on the current BB definition information about the building block instance which has a dependency on the current building block instance

The endpoint List meshProjectGroupBindings ( https://docs.meshcloud.io/api/index.html#_list_meshprojectgroupbindings ) currently allows retrieval of bindings only for a specific workspace and its projects. However, it is also necessary to support retrieving this data across all workspaces and projects, to enable broader visibility and integration.

The endpoint for retrieving workspace user groups ( https://docs.meshcloud.io/api/index.html#mesh_workspaceusergroup ) is currently available only to API users. It would be beneficial to extend support for API keys as well, enabling secure and more flexible access.

Actually building blocks can be checked out from Azure Devops Git repositories with SSH Keys. Unfortunately, SSH keys are not easy to manage: need of an Entra ID user generate secret/public key pair key pair will expire credentials (ssh keys and user credentials) must be rotated via organization policy once a year process is not fully automated A far better way is to authenticate to Azure Devops Git repo via an Entra ID Service principal. Especially because you can authenticate via Identity Workload Federation. See following article how to use git commands with Azure Devops Service principals. https://stackoverflow.com/questions/76465031/azure-devops-pipeline-git-clone-with-service-principal/76519055#76519055 https://stackoverflow.com/questions/67639199/is-it-possible-to-use-service-principal-to-access-git-repository-on-azure/76464678#76464678

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.

As an engineer I want to manage my Building Block Definition via API (or ideally even via Terraform) so I can manage the Terraform code and the definition information as one asset, and I won't have to go into the UI anymore to make changes.

As a service owner I want to have a nice UX and enforce a manageable overview for my customers. At the moment the Building Block instance name is: at the very bottom of the form -> should be the first field cannot be used as an actual input -> therefore I require my users to input a name for the service instance twice (once as a input and once as a instance name for meshStack only) I cannot update the description of the Building Block Instance name Please expose the Instance Name as potential input for the actual building block provisioning

I have implemented group replication via building blocks. I want my Azure Subscriptions to skip group replication to Entra, because otherwise the Subscription replication and building blocks fight over the same groups.