Allow workspace Building Blocks to select a workspace Payment Method as an input
F
Fabian
We would like a workspace Building Block input that:
- Displays the active Payment Methods of the target workspace as a dropdown.
- Provides the selected identifier or meshObject reference to the implementation.
- Validates that the Payment Method belongs to the workspace.
- Supports selection when creating or updating the Building Block through meshPanel and the API.
Janny the AI Product Manager
Thanks for taking the time to write this up — this is a really clear and actionable request.
Having a Building Block input that lists the target workspace’s active Payment Methods (with validation that it belongs to that workspace) and then passes the selected identifier/meshObject reference through to the implementation makes a lot of sense, especially if you want the same behavior consistently in meshPanel and via the API.
We’ll share this with the product team. Quick clarifiers to make sure we understand the desired behavior:
1) Should the dropdown show only “active” Payment Methods, or do you also want an option to include inactive ones (e.g., for migrations/auditing)?
2) When a previously-selected Payment Method becomes inactive or is removed, what should happen on update/run (fail validation, keep the value but warn, auto-clear)?
3) For the value passed to the implementation, do you prefer a stable ID, a full meshObject reference, or both (configurable)?
F
Fabian
Janny the AI Product Manager
For our use case:
- New selections should show only active Payment Methods. A previously selected inactive Payment Method should remain visible for auditing, but should not be selectable for new assignments.
- Probably not auto-clear or silently change the selection. Keep the existing reference, show that action is required, and require an active replacement before the next apply/update can succeed. Deletion should remain possible. If the Payment Method has a configured substitute, automatically switching to it and triggering a run would be consistent with existing project behavior, but I think these implementation details are probably up to you, having more insight in the backend than I do.
- We would prefer a stable meshObject reference. The implementation primarily needs the Payment Method identifier, so providing that in addition to—or as part of—the reference would be sufficient, but again, probably up to you to decide on the implementation details :)
F
Fabian
Our concrete use case is an ongoing migration of an OSB that registers cloud accounts created outside meshStack for our FinOps process. Each registration must be associated with both a workspace and one of that workspace’s Payment Methods.
The current OSB is project-scoped and inherits the project’s Payment Method. Some of these projects exist only for this association and cause recurring costs without containing provisioned cloud resources.
We would ideally need this capability within the quarter. Until then, our workaround is to retain the project-level model. If the feature is not available, we will likely have to create a technical platform for a tenant-level Building Block and keep these bookkeeping-only projects. This adds permanent cost and complexity and would make a later migration to the more appropriate workspace-level model necessary.