Lifecycle Participant
What It Is
A lifecycle participant is an application area’s declaration of responsibility for workspace resources. It tells Platform what that area creates, which other areas it depends on and how it can account for or remove what it owns. A product manager uses the concept to ask whether a complete workspace build or deletion reaches every application area involved.
Participants give orchestration a common vocabulary without transferring ownership of business records. CRM still owns its contacts and Commerce its orders. Platform coordinates their lifecycle work through declared operations. The declaration and implementation must agree for a plan to describe the work that actually runs.
What It Is Not
A participant is not a customer user or a permission role. Nor is it a durable job. The job invokes participants, while the participant supplies one application’s work and inventory. It is also broader than a table: related records, default configuration and external resources can belong to the same responsibility.
Declaring a resource does not establish that its removal is implemented. A declaration can expose deferred or unsupported coverage, which must remain visible when interpreting completion.
How It Is Used
Application teams register participants as they introduce workspace-owned resources. Platform uses dependencies to construct the build order and its reverse for removal. A description call can run before a workspace exists, allowing planning without creating records first. Other operations name the workspace and participant being acted on.
Completeness checks compare database tables with declarations and detect omissions or duplicate ownership. Platform additionally keeps remote declarations and enablement switches. Drift between those copies and the owning application can hide resources or stop execution. Staff reviewing a failed plan need the difference identified rather than an unexplained skipped application.
Its Facets
Manifest. The published declaration names identity, application, resources, defaults, dependencies and supported operations. It is the plan’s account of responsibility.
Dependencies. A participant names resources it needs established first. Reversing that order lets dependents go before their prerequisites during deletion.
Enablement. Platform controls inclusion of remote participants. An application with none enabled is absent from orchestration calls, even if its own implementation exists.
Resource ownership. Table, file and external-resource declarations explain the inventory expected from that participant and the available removal method.
Defaults and ledgers. Seed sets describe starter configuration. The ledger prevents retries and later reconciliation from overwriting customer choices.
Supported operations. Provisioning, readiness, purge and inventory form the common work; reset, initialization and export vary by application and participant.
Resource registration. Stable external resource names and register rows allow adoption on retry and preserve an account of ownership.
Export classification. Datasets and withholding decisions explain what a full workspace package includes or omits, separately from deletion coverage.
How It Relates
Provisioning asks participants to build and verify. Loading reset reaches only the participants classified for removal. Deletion purges the planned resources and uses inventory to judge completion. Baseline reconciliation uses participant defaults while the export coordinator uses datasets. Application owners retain responsibility for the records behind these declarations.
What It Could Become
The product should reconcile Platform’s remote declarations with their owners before relying on full cross-application deletion. Websites also needs removal and inventory for its declared CMS resources. Consistent input validation and clearer optional-operation contracts would make participant boundaries easier to test without turning each implementation detail into another concept.