Build A Workspace And Open It
What It Does
Construct participant resources in dependency order, verify readiness and activate the workspace. Ledgered defaults and deterministic provider adoption support repeated construction. Commerce adoption can recreate a removed default. Repeated activation preserves its recorded first instant.
The Flow
When Something Fails
Refuse a changed order and apply build failure handling. A retry may already have resources from an earlier attempt. Retry eligible failures, then settle failure without compensation. Completed resources remain even if a later participant fails. Refuse incompatible existing administration standing. Invitation delivery can precede later build failure. Retry eligible errors and fail if preparation cannot finish. Provider resources can exist before the build completes. Return remote errors to job handling and retry under task policy. Committed remote work remains; timed-out invocation can still be running. Refuse readiness with the missing resources. The constructed resources remain while the workspace fails provisioning. Repeat activation under task retry policy. Database activation can commit before later task work succeeds. Application-enablement failure can fail the task; the other follow-up failures are logged under their own handling. An active workspace can have a failed build attempt and missing follow-up results.
Open Design Questions
Participant declarations can drift without changing order. Serial execution differs from the planned parallel stages, and post-activation follow-up can fail after the workspace opens.