Every few months someone asks me to help “get rid of” a batch of records — old contacts, dead accounts, products nobody sells anymore. And every time, the first conversation is the same one: in Dynamics 365, delete is not the tool for retirement. The platform has a whole lifecycle mechanism built for exactly this, and once a team starts using it, most of their delete requests quietly disappear.
Deactivate: retirement with a paper trail
Nearly every record has a status — Active or Inactive — and a Deactivate command right on the form. Click it and the platform explains the deal plainly:
Note the wording: the record is set to inactive, and other records that reference it keep working. That last part is the entire argument. A deactivated contact still appears on the account’s history, still shows on the old cases they raised, still resolves in every lookup that already points at them. Nothing breaks. The record just stops being current.
What inactive looks like
The form goes read-only, a banner states the status, and the command bar swaps Deactivate for Activate and — only now, meaningfully — Delete. Inactive records also drop out of the default views: “My Active Contacts” and every lookup search show only active records, so retired data stops cluttering daily work without ceasing to exist. If you ever need the history, the “Inactive Contacts” view has it all, and reactivation is one click and one confirmation:
Fully reversible, fully auditable — the opposite of delete in every way that matters.
What delete actually does
Delete is permanent, and it cascades. Depending on relationship behavior, deleting an account can take its child contacts, activities and notes with it; at minimum it leaves holes where references used to be — the case that says the customer is “(unavailable)”, the report whose totals changed retroactively. There is no recycle bin in the classic sense (environments now offer a recycle-bin window for a limited period, but that is disaster insurance, not a workflow). My rule: delete is for mistakes, deactivate is for history. A record created in error, a duplicate born from a bad import — delete. A customer who churned, an employee who left, a product you discontinued — deactivate, always, because the past transactions attached to those records are your data.
Status reasons: the underrated half
Both states can carry status reasons — customizable labels for why a record is where it is. Out of the box, an inactive case distinguishes Cancelled from Resolved from Merged; and you can add your own reasons per table in the maker portal (Inactive: “Churned”, “Out of business”, “Merged into parent”). Cheap to add, and suddenly your inactive pile is a queryable dataset instead of a graveyard: “how many accounts did we lose to churn versus acquisition last year” becomes a view, not an archaeology project.
So next time someone asks you to clean house, reframe the request: what they want is for old records to stop showing up — and that is deactivation’s whole job. Save delete for the records that should never have existed.
