Table of Contents


About the Recycle Bin

When records are deleted in the portal, the platform soft-deletes them — they remain in the database with an IsDeleted flag set and appear in the Recycle Bin. Administrators can review deleted items, restore them individually or in bulk, or permanently delete them to free the names for reuse. A scheduled cleanup permanently removes Recycle Bin items older than 30 days.

This page is the administrator's overview. The operational workflow (restore, restore all, empty, permanent delete) and the troubleshooting guidance each have their own pages.


Where the Recycle Bin Lives

  • The Recycle Bin page is at Setup > Manage > Recycle Bin.
  • The page is admin-only.

What Appears in the Recycle Bin

Soft-deletable platform records appear in the Recycle Bin after they are deleted. Each Recycle Bin row identifies the deleted record by:

ColumnWhat It Shows
ActionPer-row Restore and Del actions.
EntityThe entity the deleted record belonged to.
Record NameThe deleted record's name field value at the time of deletion.
Modified ByThe user who last modified the record (typically the user who deleted it).
Last Modified DateWhen the record was last modified. The list is sorted by this column, most recent first.

Mobile layout shows the same fields as a list, with per-item Restore and Delete controls.


Restore Compatibility

Restore works only for entities that the platform soft-deletes. When you restore a record, the platform clears its IsDeleted flag so the record becomes active again. Entity types that have no IsDeleted field cannot be soft-deleted, so they cannot be restored — if a restore is attempted on one, it fails, and an error is logged.

In practice, this covers the record-level and named-configuration items that follow the soft-delete pattern, such as standard and custom entity records, Reports, Folders, Storefront Settings, Journeys, and similar configuration records. Items that are removed immediately (hard-deleted) rather than soft-deleted never appear in the Recycle Bin and are not recoverable from it.


30-Day Retention

Items in the Recycle Bin are automatically permanently deleted after 30 days. A scheduled background job runs on the platform's CronJob pipeline and removes items whose creation in the Recycle Bin is older than 30 days.

Cleanup characteristics:

  • Processes items in batches.
  • Has a time cap of approximately 2 minutes per run. If the backlog exceeds what can be cleaned in one run, the remainder defers to the next scheduled run. An informational message is logged when the time cap is reached.
  • Uses per-item delete (not bulk SQL) so business logic, workflows, and related-record cleanup still execute for each removed item.
  • Per-item exceptions are logged but do not stop the rest of the batch.

Administrators do not need to schedule or configure this cleanup — it runs as part of the platform's standard CronJob pipeline.


Unique Names and the Recycle Bin

While an item is in the Recycle Bin, it still holds its unique name. Creating a new record with the same unique name fails until the item is either restored or permanently deleted from the bin. The Dashboard surfaces a notification when a unique-name conflict involves an item still in the Recycle Bin, so administrators know to clear the bin entry to free the name.


Restore-All Ordering

When you click Restore All, the platform restores items in dependency order. Records without a parent reference (top-level items) restore first; then records whose parent reference is no longer in the bin restore in subsequent passes. The process stops when no items can be restored in a pass — this prevents infinite loops on circular references and ensures only items whose parents are present can come back cleanly.


Permissions

  • The Recycle Bin page itself is admin-only.
  • Restore and Restore All require Edit permission on Recycle Bin.
  • Per-row Del and Empty require Delete permission on Recycle Bin.
  • In typical portal configurations these all align with the Administrator System Role.

Use Cases

  • Recover an accidentally deleted record. An administrator deletes the wrong Account or Custom Entity record; they restore it from the Recycle Bin before the 30-day window expires.
  • Free a unique name for reuse. A deleted record is blocking a new record with the same name. The administrator permanently deletes the bin entry and the new record creates cleanly.
  • Bulk-undo a sweeping delete. A bulk-delete operation removes more records than intended; Restore All brings everything back in the correct parent-then-child order.
  • Clear stuck bin entries. If a few items remain after an Empty operation, they are usually being held by something that still references them — for example, a foreign-key constraint from a related record, or a validation rule. Because permanent deletion can't break that reference, the item stays in the bin. To clear it, first identify and remove the blocker (delete or repoint the related record, or resolve the validation issue), then use the per-row Del on the leftover item so it deletes cleanly.

Troubleshooting Tips

  • If Restore fails on a specific item, the underlying entity may not support soft-delete. Check the system log for an entity-cannot-be-restored message.
  • If Empty doesn't appear to make progress, items may be blocked by foreign-key or validation constraints. The platform logs per-item exceptions and continues; identify the stuck rows and remove their blockers.
  • For full symptom-by-symptom resolutions, see Recycle Bin Troubleshooting.

 

Recycle Bin Checklist >>

Last updated on 6/30/2026

Attachments