Finish offboarding on a clear schedule
After a marked organisation’s recovery deadline passes, a background job removes it through the ordinary deletion operation. The same child-lifecycle rules apply as on an explicit delete.
The operator controls the retention period, schedule and work per run. A failure on one organisation is recorded without preventing the job from attempting the others.
Example — Honor the deadline already given
An organisation is marked under a thirty-day policy. Shortening the default tomorrow does not move that organisation’s stored deadline; the purge job uses the date already recorded.
For engineers
Configure the operator policy
In backend-api/src/saas-config.backend.ts, the optional tenantTeardown block accepts:
tenantTeardown: {
retentionWindowDays: 30,
purgeCronSchedule: '0 3 * * *',
purgeBatchSize: 50,
},
These are the current defaults, including when the entire tenantTeardown block is omitted. Omitting it does not disable purge. Choose the period to match the application’s obligations. The schedule controls when due organisations are processed; it does not change their individual stored deadlines.
Follow the batch through normal deletion
Application startup registers the engine’s organisation-purge batch. It selects organisations with status: DELETED and an existing purgeScheduledAt earlier than the current instant, bounds the attempted set and invokes the route-less internal delete operation for each.
This reuses cascade and retention behavior instead of maintaining a second teardown algorithm. A child configured for retention and impersonalisation follows that policy; do not describe purge as unconditional physical deletion of every related business record.
Verify that scheduling reaches a running executor
Registration makes the batch available; it does not prove a scheduled run happened. The application’s cron registration must reach the crontabs manager, and the background execution path must have its queue connection and consumers running. Startup can continue when queue initialization or cron synchronization has failed, so a healthy HTTP endpoint alone is not proof that cleanup is operating.
Check the registered organization-purge schedule, then a completed run and its result. Compare the stored deadline with the actual execution time; an organization becomes eligible after its deadline, and removal occurs when a successful run reaches it. Do not rewrite stored deadlines merely to clear a backlog.
Operate failures and backlog explicitly
The result distinguishes attempted, purged and failed organisations. dueOrganizations is the number attempted in this bounded run, not the total backlog; purged and failed describe those attempts. A failure is logged with the organisation and deadline; the next eligible run can attempt it again. A run bounded by batch size also logs that more work may remain.
The organisation deletion audit hook runs on this internal delete path as well as the administrator path. Its evidence records the organisation from the pre-deletion snapshot, which remains meaningful after the live row has disappeared.