ActiveManage never destroys data on a normal delete. Every datastore row has a MSTisdeleted column; deleting just flips it from 0 to 1. The row stays in the database, hidden from listings, recoverable. This is one of the platform's most defensive design choices and it has saved many an admin from a fat-fingered delete.
Why soft delete?
Three concrete reasons the platform defaults to soft delete:
1. Accident recovery
Most data is deleted by mistake — wrong row picked, wrong filter applied, wrong user clicked. Soft delete gives you a one-click undo: open the Trash, find the row, click Restore. Hard delete would mean restoring from backup, which is hours of work even when it goes well.
2. Audit trails
Records survive long enough to satisfy compliance retention rules without admins having to remember to back up. For industries with regulatory data-retention requirements (healthcare, financial services), soft delete is a free-rider on the platform's storage rather than a custom audit feature.
3. Referential integrity
Other rows that reference the deleted row don't break — the linked row is still there, just flagged. An order line that references a deleted product still resolves; the platform's queries filter out deleted rows from listings but the row itself is still queryable when needed.
Viewing the Trash
On most datastore lists there's a Trash button (or filter toggle) that flips the view between active rows and soft-deleted rows. Trash rows have an extra Restore action that flips MSTisdeleted back to 0.
The Trash view is permission-controlled separately from the main list. Typically only admins can see the Trash — regular users see only active rows and have no idea soft-deleted rows exist.
Three patterns for using soft delete well
Pattern 1: Auto-purge old soft-deletes
For datastores where the data is genuinely transient (logs, drafts, temporary records), keeping soft-deleted rows forever bloats the database. Set up a scheduled Task that hard-deletes rows where MSTisdeleted = 1 and the deletion timestamp is more than N days old. Common N values: 30 for low-importance data, 90 for moderate, 365 for compliance-bearing.
Pattern 2: Confirm-before-delete UX
The platform's default delete is a single click. For destructive actions on important data, configure a confirmation dialog. The Browse View configuration supports per-action confirmation messages.
Pattern 3: Soft-delete on cascade
When you delete a parent row, you often want to soft-delete its children too. Use a post-update trigger or a Custom PHP callback to cascade the MSTisdeleted flip down to related rows.
Permanent deletion
Truly removing a row from the database requires a hard delete. That's typically run from:
- The database admin tools directly (DBA opens a SQL client and runs DELETE).
- A custom admin page or row action you build for purging.
- A scheduled task that purges rows older than a configurable retention period.
- A GDPR-style "forget me" workflow that hard-deletes a specific user's data on request.
Warning: Hard delete is irreversible. If you have linked rows referring to the row you hard-delete, those references will be orphaned — queries that try to follow the link will return blank or error. Plan cascade behaviour before hard-deleting anything important.
Soft delete and external integrations
If an external system syncs with the datastore (via the API or Table Sync), they need to handle soft-delete somehow:
- Hidden from API by default — the platform's API filters out soft-deleted rows for most endpoints. External systems just see the row disappear.
- Explicit "include deleted" mode — some endpoints support a parameter to include soft-deleted rows. Useful for sync systems that want to mirror the platform's delete state.
GDPR and the right to be forgotten
Soft delete doesn't satisfy GDPR's right-to-erasure on its own — the data is still in the database, just flagged. To genuinely comply, build a hard-delete workflow that:
- Identifies all rows belonging to the requesting individual across all relevant datastores.
- Hard-deletes them (DELETE rather than UPDATE).
- Records the request and the deletion timestamp in a separate audit-only log so you can prove compliance.
- Cascades to related data as appropriate.