Carry erasure into connected services
Personal information can continue living at a connected service after the application removes its own copy. Wildo gives integrations an erasure hook and collects their outcomes alongside the local result.
The report preserves the distinction between completed work and a service that still needs attention.
Example — Follow a request beyond the database
A person’s local records are processed, then the billing integration handles its customer data. If that provider cannot complete a step, the application receives a specific outcome to follow up instead of treating local success as the whole request.
For engineers
An external effect declares a stable effectRef, an appliesTo(subjectResourceType) predicate and an async run(context) returning an outcome. Register it with SubjectErasureExternalEffectsRegistryBackendService during backend setup. Billing demonstrates the contract: the effect declares exactly which subject resources it owns before its run method does any provider work.
Source: billing-subject-erasure-effect.backend.ts, effect opening; the remaining provider work is omitted.
export function createBillingSubjectErasureEffect(
dependencies: BillingSubjectErasureDependencies,
): SubjectErasureExternalEffect {
return {
effectRef: BILLING_SUBJECT_ERASURE_EFFECT_REF,
// USERS and USER_SELF share the same user subject; organisation teardown is separate.
appliesTo(subjectResourceType: ResourceType): boolean {
return subjectResourceType === CoreResourceType.USERS
|| subjectResourceType === CoreResourceType.USER_SELF;
},
The shortened comment above summarizes the source comment. Backend startup registers this effect through SAAS_SERVICE_TYPES.SubjectErasureExternalEffectsService when billing is configured. A custom integration supplies its own stable reference, subject predicate and implementation. Re-registering the same reference replaces it rather than appending another effect. The run context contains subject IDs and scope, not the personal fields already scrubbed; resolve provider identifiers from the integration’s own records.
Effects execute sequentially after the local commit. They cannot roll back a remote API call or the completed local erasure. Return step-level outcomes that let the operator distinguish completed work, nothing to erase, partial work and failure. The runner retries clean FAILED outcomes or thrown failures within a bound; it does not automatically replay a reported PARTIAL. Return provider failures as structured outcomes with per-step detail. Throwing loses that detail and can trigger a retry, so external actions must tolerate replay; do not rely on an exception to roll back work already accepted by a provider.
Inspect report.externalEffects with selectIncompleteExternalEffects rather than inventing a status comparison. Persist the outcome needed for follow-up without copying erased personal values into operational logs.
HTTP_API-backed resources declare their own erasure stance and subject link. A declared external erasure operation removes the matching remote rows through the adapter. An acknowledged non-erasure is a per-request controller decision recorded as incomplete, not proof of removal. Integrations that store personal information must register their own responsibility; the registry cannot discover every third-party copy.