Keep financial history connected after closure
Closing a customer account should not scatter its financial history. Wildo retains the billing records and their account relationships, so invoices, subscriptions and usage remain attributable after the owning workspace is removed.
Example — Close a workspace and retain its invoice history
The workspace closes, while the retained billing account still connects its invoices and subscription records for accounting follow-up.
For engineers
The core relationship registry disables the parent-delete cascade from a workspace to its billing account and to each financial child family. The invoice scope relationship is one example:
The following selected excerpt is from resources-registry.shared.core.definitions.ts; the surrounding module and explanatory source comments are omitted.
...createPolymorphicScopeRelationships(invoiceRefsPolymorphicDeclaration, {
nature: RelationshipNature.COMPOSITION,
childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the billing-retention note above.
}),
These records are retained rather than moved behind a generic hidden/frozen resource state, because accounting still needs ordinary access to them.
Do not delete the financial anchor directly
The relationships from each billing account to its subscriptions, invoice references, usage records and credit pools declare a different lifecycle strategy. It tears nothing down: the account’s delete is refused while any of those children still names it.
The following selected excerpt is the invoice relationship from the same file, without its source comment:
...createPolymorphicRelationships(
billingAccountsPolymorphicDeclaration,
invoiceRefsPolymorphicDeclaration,
ResourceRelationshipCardinality.ONE,
ResourceRelationshipCardinality.MANY,
{
nature: RelationshipNature.COMPOSITION,
childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } },
contextPolicy: {},
},
),
The service tier checks these relationships before a single or bulk delete writes anything, on every variant of the operation. It refuses with a conflict naming every blocking family. A retained child still blocks, and the refusal then reports it without disclosing the retained row. If a child family cannot be read, the delete fails closed with a configuration error rather than treating the family as empty.
Use the normal scope lifecycle and subject-erasure operations, not a direct repository purge. Personal-data erasure and financial retention have different effects: the person’s identifying data can be treated while financial amounts and relationships remain. Provider-side erasure also keeps the provider customer identity resolvable for retained records.
The application still determines its applicable retention obligations and operating procedures. This mechanism preserves the declared financial relationships; it does not choose a universal legal retention duration or imply that every custom table has the same treatment.