Knowledge · Business Operations

    Soft Delete, Archive, Restore and Purge

    Four different operations that are routinely confused. What each one means for visibility, recoverability, reporting and legal obligation.

    What is the difference between soft delete, archive and purge?

    A soft delete hides a record but keeps it recoverable. An archive keeps it visible on request but removes it from active work. A restore returns a soft-deleted record to active use. A purge destroys it irreversibly. Only the last one is actually deletion, and it should be rare, deliberate and recorded.

    Key takeaways

    • Removing something from a list is not the same as destroying it.
    • Soft-deleted records must be excluded by default, not by remembering to filter.
    • Restore has to reattach history, not just flip a flag.
    • Purge is a separate, privileged, recorded operation with a different authority.
    • Deletion of financially or legally significant records is a policy question first.

    Why 'delete' is the wrong default for operational records

    In a service business, the records people most want to tidy away are the ones with the longest tail of consequence: an old lead that resurfaces, an estimate that was declined and then revived, a job that becomes a warranty claim two years later. Destroying them to clean a list trades a moment of neatness for the permanent loss of the only account of what happened.

    The four operations and what each one guarantees

    • Soft delete: removed from every active view, still stored, still recoverable, still present in history.
    • Archive: intentionally out of the working set but retrievable by anyone who looks, typically for completed or dormant work.
    • Restore: returned to active use with its identity, relationships and history intact.
    • Purge: irreversible destruction, appropriate for erasure obligations and for genuine mistakes, and for very little else.

    The failure that makes soft delete worthless

    A soft delete only works if the exclusion is universal. One report, one export, one automation or one search that forgets the exclusion and the deleted record reappears — often in front of a customer. The filter belongs in shared query paths and policies rather than being reapplied by hand at every call site.

    Who is allowed to destroy something

    Hiding a record and destroying one are not the same authority. Soft delete can reasonably belong to the people doing the work; purge should sit with a senior role, be recorded with actor and reason, and be resistant to being performed casually from a list view.

    Where URBLD fits

    URBLD uses server-mediated soft deletion: records carry a deletion timestamp and active queries exclude them. Leads and jobs are treated as existentially critical and are never hard-deleted through ordinary paths. Deletion and restore write to the audit trail with the resolved actor and entity, and identity threading means a restored record keeps its organization-scoped lifecycle number rather than being reissued as a new one.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Business Operations

    The daily mechanics: workflows, checklists, scheduling and handoffs.

    Browse Business Operations
    Share this page