Deleting Records And The Trash

Deleting a record removes it from your application. This chapter explains how deleting works, what it takes with it, what can and cannot be recovered, and why in most applications the safest assumption is that a deleted record is gone for good.

Read This First

In most applications, deleting is permanent. Assume it cannot be undone.

A recycle bin is not something you get automatically. For a deleted record to be recoverable, three separate things all have to be true in your application:

1. Your administrator has switched the application from truly deleting records to keeping them hidden instead.
2. The Trash screen has been enabled for your application at all — it is a separately licensed area, not part of the standard set of screens.
3. Your role has been granted access to the Trash screen and permission to restore from it.

If any one of those is missing, pressing Delete removes the record for good, and nothing in the interface will tell you which situation you are in beforehand. The confirmation screen looks exactly the same either way.

There is a quick test: look in the navigation panel, under the Administration group, for a Trash entry (a waste-basket icon). If you cannot see it, you have no recycle bin — either because the feature is off or because your role does not include it. Do not delete anything you might want back.

Seeing the entry is not a guarantee in the other direction. The screen can be present while the application is still set to remove records for good, in which case Trash stays permanently empty. Only your administrator can tell you which of the two settings is in force.

Even where Trash exists, it is not a complete safety net. Restoring a record brings back the record, but not necessarily everything that was attached to it — see What Restore Does Not Bring Back.

What Deleting Actually Does

When a record is deleted it disappears everywhere at once:

• from every list screen, board, calendar and card layout that showed it
• from the related-record lists on other records
• from counts, totals and calculations
• from search results
• from any dashboard widget or chart built on that data

Other people see the same thing the next time their screen loads its data. Lists do not update themselves, so a colleague with the screen already open will keep seeing the record until they refresh — see List Screens.

Deleting is a per-record action. Deleting one order does not delete the customer it belongs to, and deleting a customer does not delete their orders — but it does change what those orders show. That is covered in What Happens To Everything Attached. The one exception is a rule your administrator built deliberately, which can make one deletion trigger others.

Why It Matters

Business data is rarely as disposable as it looks on screen. A single record often carries invisible weight: it may be pointed at by dozens of others, it may be the reason a total adds up, and it may be part of a legal or accounting trail.

Because the application has no undo and usually no recycle bin, the moment of pressing Delete is the moment the decision becomes final. It is worth a few seconds of checking, and it is worth knowing that there is almost always a better alternative — see Better Alternatives To Deleting.

How To Delete A Record

Delete is one of the standard record actions, so it appears in the same places as Edit and Duplicate. Whether you see it at all depends on your role: if you are not permitted to delete a given kind of record, the entry is absent rather than grayed out. See Roles, Groups And Permissions.

From The Record Itself

1. Open the record.
2. Open the Actions menu — the small chevron-down button next to the record title, or in the page's top bar when the record fills the whole page.
3. Choose the delete entry. It is usually labeled Delete, shown in red with a waste-basket icon, though your administrator can rename or re-icon it.
4. Confirm on the screen that appears.

Your administrator may also have placed a delete button in the row of buttons across the top of the record instead of, or as well as, in the Actions menu.

From A Row In A List

On table layouts each row has its own menu, opened either by right-clicking anywhere on the row or by clicking the small chevron in the narrow control column at the left-hand end of the row, next to the tick box. The same delete entry appears there.

The menu is built fresh each time you open it, for that specific row. So it is normal for Delete to appear on one row and not on another — your permission to delete may be limited to certain records.

The cards layout has the same menu per card: hover over a card and a three-dots button appears in its corner, and right-clicking the card works too. The simple list, board and calendar layouts have no per-record menu at all — on those, open the record first and delete from the Actions menu.

Deleting Several Records At Once

On a table layout you can tick several rows and then use the row menu to delete all of them together. The confirmation screen then lists every selected record, and the header counts them.

Selection works only on table layouts, and there is no on-screen counter of how many rows you have ticked — only the ticked boxes and the tinted rows tell you. Scroll back up and check before confirming. Full details are in Selecting Records And Bulk Actions.

Example You filter the Tasks list to Status = Canceled, tick eleven rows, right-click and choose Delete. The confirmation reads "Delete 11 Tasks" and lists all eleven by name. That list is your last chance to notice that row seven is actually a task you still need — once you press the red button, all eleven go at once.

The Confirmation Screen

The confirmation opens as a pop-up sheet over whatever you were doing. It contains:

• a heading counting what is about to go, using the name of that record type ("Delete 3 Invoices")
• a question asking whether you really want to delete them
• one line per record, showing the record type, a number preceded by #, and the record's title
• a red delete button
• a plain Cancel link that just closes the sheet and does nothing

Read the lines. They are the only place where the exact records are spelled out, and the # number is worth noting: if you later need an administrator to look for the record, that number is the most useful thing you can give them.

Your administrator can replace this standard confirmation with a screen of their own for a particular kind of record, so on some record types it may look different and carry extra warnings. Read whatever it says before confirming.

If you open the confirmation as a full page rather than a pop-up (which happens if you hold Ctrl, Cmd, Shift or Alt while clicking the action), there is no Cancel link. Use your browser's Back button instead.

What Happens After You Confirm

• A short green message strip confirms the deletion — one strip per record, so deleting five records produces five strips.
• The row vanishes from every list on screen without a page reload, and any count badge next to it drops by one.
• If the record's own detail sheet was open, that sheet closes by itself.
• The screen behind refreshes.

Message strips appear at the bottom right and disappear after about five seconds. There is no history of them, so if you look away you will not be able to check afterwards what the application told you.

Deletions That Do Not Ask Twice

Not everything that removes data asks for confirmation. These are the ones that catch people out:

Comments and file removals are the two that most often surprise people, because both are a single small icon sitting next to content you were only reading. Neither can be undone, and neither goes to Trash. See Comments And Mentions and Uploading Files And Images.

Buttons your administrator has added can be set to ask a question before running, and that question can quote the record's own values ("Really cancel order 2024-118?"). If a custom button does not ask, that is a choice someone made when it was built, not a sign that it is harmless.

When A Deletion Refuses To Happen

Sometimes pressing the red button produces a warning message strip beginning "Error deleting the record." followed by an explanation. Nothing has been deleted.

The usual reasons:

• The record is a container that still has contents. A folder that still holds records or sub-folders refuses to go, with a message saying so ("Folder contains child folders." or "Folder contains assigned records."). Empty it first, or move its contents elsewhere. A folder that has been pinned also refuses.
• Your application has a rule against it. Your administrator can set up rules that block deletion in defined circumstances — for example, refusing to delete an order once it has been invoiced. Depending on how the rule was written you may get a clear explanation, a generic error, or nothing happening at all.
• You are not permitted to delete this particular record. Permission can be limited to a subset of records, so the button can be present while the deletion is refused.
• The record is one the application depends on to run. Some built-in records — the built-in roles, for instance, and the record types themselves — refuse to be deleted by anyone. You are unlikely to meet these unless you also administer the application.

If you selected several records and one of them fails, none of them are deleted — the whole batch is rolled back together. Confusingly, you may still see one or more green "deleted" strips next to the error, because those were produced before the failure was discovered. Trust the error, not the green strips, and refresh the list to see what is actually there.

One thing the rollback does not undo is file removal. Attachments on the records the application had already got through are deleted from storage as it goes, and putting the records back does not bring those files back. After a failed batch, check the file fields of the records you selected.

If instead you get the generic "Error When Processing Request" dialog, that is a different problem — see When Something Goes Wrong.

What Happens To Everything Attached To The Record

This is where deleting reaches further than people expect.

Files and images. Attachments on the record are deleted from storage at the moment you confirm — not later, and not only if the record is permanently removed. Unless your administrator has separately turned off the truly-delete behavior for files, the files are gone even in applications that keep the record itself in Trash.

Comments. The discussion on the record is not deleted. Where a recycle bin exists and the record is restored, its comments come back with it.

Tags. Every tag assigned to the record is unassigned. This happens whether the deletion is permanent or not, and restoring the record does not put the tags back.

Mentions. If the record was mentioned in someone's comment, that connection is removed, and it is not restored either.

Change history. The record's activity history goes with the record. Note that deletions are never written into a record's own activity tab in the first place — the tab records changes to a record, not its removal. Your application may keep a separate log of deletions if that has been switched on for the record type; it lives on an administration screen you will not normally have access to.

References from other records. This is the important one, and it does not work the way most people assume.

References Do Not Block A Deletion

The application does not refuse to delete a record just because other records point at it. It deletes the record and quietly leaves the pointing fields blank:

• A field on another record that pointed at the deleted record becomes empty.
• A link that listed the two records against each other disappears from both sides.
• Because empty fields are usually hidden on detail screens, the field may vanish from view entirely rather than showing as blank.

Nobody is warned, and no message is shown on the affected records. The people who work with those records find, later, that a field they relied on is empty.

Whether that is recoverable depends on which kind of deletion your application performs, and this is the one place where the difference really matters:

• Permanent deletion (the usual setting) breaks the connection for good. Restoring the information later means setting the field again on every affected record, by hand.
• Deletion into Trash only hides the target. The pointing fields go blank because what they point at is no longer visible — but restoring the record from Trash makes them show it again, with nothing to redo.

Example A supplier record is deleted from the Suppliers list because "we do not buy from them any more". Nothing refuses, nothing warns. The next morning, forty purchase orders have an empty Supplier field — and because empty fields are hidden by default, on most of them the Supplier row is no longer on the screen at all. The orders are intact; the connection is not. If the application deletes for good, someone now has to set the Supplier field again forty times. If it keeps deleted records in Trash, restoring the supplier brings all forty back to normal at once — which is exactly why it is worth knowing, before the fact, which of the two your application does.

Checking What Depends On A Record Before You Delete It

Because references go quiet without anyone being told, the check is worth doing before you confirm.

Open the record and look at its tabs. Unless your administrator has changed the set of tabs, or your role does not include it, there is a tab called Mentioned in that lists everywhere this record is referenced from. It has up to three parts:

• Records that point at it through a field — grouped by record type, then by which field does the pointing.
• Records that mention it in a comment — each row noting whether the reference came through a field or a comment.
• Configuration references — mostly relevant to administrators.

Two things to know about this tab:

• The per-field sub-sections in the first part start collapsed. A block that looks empty usually is not — the count is in the sub-heading, next to the arrow, as "(340)". Click each sub-heading to expand it.
• It lists twenty items at a time, with a pager underneath. A sub-heading reading "(340)" means 340 records will lose a value, not the twenty you can see.

The tab shows only what points at this record. What this record points at is on its Overview tab, and deleting this record does not affect those.

A second check is worth doing on the other side: go to the list of the record type you are worried about and filter it by the field that points at your record. That gives you the same number in a form you can act on — export it, or reassign the records first. See Filtering Your Data.

Finally, be aware that this tab is filtered by your permissions. Record types you are not allowed to see are left out entirely, so the real number of affected records can be higher than the number you can see.

The Trash Screen

Only some applications have this screen, and only some roles can reach it. Everything in this section is conditional on your application having it.

Where It Is And What It Lists

Trash sits in the navigation panel, in the Administration group, with a waste-basket icon. The page heading is Trash.

It lists deleted records across all the record types you are allowed to see — not one type at a time. The table has these columns:

At the end of each row are two small icons: an eye to preview the record, and a circular arrow to restore it.

Records are shown fifty to a page, the most recent deletion first, with a pager at the bottom. The columns are not sortable, so the order is always newest-deleted downward. Above the table a line tells you which page you are on and a badge gives the total number of items.

Finding Something In Trash

The left-hand column holds the filters:

• Search by name — matches text inside the title
• Type — narrows to one kind of record
• Deleted by — narrows to one person
• Deleted from and Deleted to — a date-and-time range

Fill in what you know and press the apply button. Active filters appear as small chips above the table, and a reset link appears next to the "Filters" heading at the top of the column to clear them all.

On a wide enough screen you can drag the right-hand edge of the filter column to make it wider, and double-click that edge to put it back. That width is remembered for the current browser tab only, so a new tab starts at the default again.

Previewing Before Restoring

The eye icon opens a preview: the record's title, its type, its number, when it was deleted and by whom, and then the record's fields exactly as they would appear on its detail screen.

The preview deliberately shows values only. There are no tabs, no Actions menu, no comments and no related lists. It is there so you can confirm you have the right record, not to work in.

A Restore button sits at the top right of the preview.

Restoring

Click the circular-arrow icon on the row, or the Restore button in the preview. A short browser confirmation asks "Restore this deleted item?". Confirm, and:

• the record becomes visible again, so it reappears in its normal lists the next time each of them loads or is refreshed
• a message strip confirms "Item restored from trash."
• any open pop-up windows close, and the Trash listing redraws without the row

If your role does not include restoring, you get a message saying you do not have permission, and nothing changes.

What Restore Does Not Bring Back

Restoring makes the record visible again. It does not rebuild what was genuinely cleared when the record was deleted.

• Attached files are not restored. Unless your administrator has turned off the truly-delete behavior for files as well, they were removed from storage at the moment the record was deleted, and restoring the record does not bring them back. The file field comes back empty.
• Tags are not restored. Tag assignments are removed outright whichever kind of deletion is in force, so the record comes back untagged.
• Mentions are not restored. References made from other people's comments are removed outright too, and stay broken.
• Comments are restored, because they were never removed.
• Fields on other records that pointed at this one start working again. They were never actually cleared — they only looked empty while the record was hidden.
• The record's own field values and its activity history come back unchanged.

So a restore gives you back the record, its values, its history, its comments and its place in the web of relations. What it cannot give back are attached files, tags and comment mentions.

The Ninety-Day Window

A note under the filters reads that items deleted more than a certain number of days ago are hidden. That number is ninety, and it is fixed — it is not something your administrator can raise for you from the Trash screen.

Once a deletion passes that age it drops out of the listing, out of the counts and out of reach: it can no longer be previewed or restored from this screen, and a link to it answers "Item not found in Trash."

Treat ninety days as a hard deadline. Anything you might want back has to be recovered inside it.

There Is No Undo

The application has no undo — not for deleting, not for editing, not for anything else. Ctrl+Z works inside a text box you are still typing in, and nowhere else.

Related consequences worth knowing:

• Saving over someone else's edit is not warned about. If you and a colleague edit the same record at the same time, the second save wins silently. See Creating And Editing Records.
• A record's activity tab shows previous values but cannot restore them. Where that tab is available, it tells you what a field used to contain, so you can retype it — that is as close to undo as the application gets, and it only covers fields your administrator marked for tracking.
• Dragging a card between board columns, or reordering a sortable list, saves immediately with no confirmation and no way back other than dragging it again.

Better Alternatives To Deleting

Deleting is the least reversible tool available, and in most business situations it is not the right one. The usual alternative is to leave the record in place and mark it as no longer active.

Common shapes this takes:

Why this is usually better:

• Everything that pointed at the record keeps pointing at it. No fields are emptied.
• History, comments and attachments stay intact and readable.
• The record can come back into use without being rebuilt.
• The saved views your team uses can filter the inactive ones out, so day to day nobody sees them.
• If you were wrong, changing a field back takes two seconds.

Example A supplier goes out of business. Rather than deleting them, someone sets their Status field to "Inactive". The Suppliers list already has a saved view called "Active suppliers" that filters on that field, so the everyday list is clean. Two years later an auditor asks which supplier was behind purchase order 4471 — the answer is still there, on the order, exactly as it was. Deleting would have left an empty field and no way to answer.

If your record type does not have a field like this, you cannot add one yourself. Ask your administrator — this is one of the most common and easiest requests to make, and it is described alongside others in What To Ask Your Administrator For.

A useful way to phrase it: "On [record type], please add a status field with the values [list them], set the default to [value], make [value] the one that hides a record from our normal list, and update our saved views to filter it out. We would rather mark records inactive than delete them."

If You Deleted Something You Needed

Act immediately. Every hour makes recovery harder, and the ninety-day window in Trash is the outer limit even in the best case.

1. Stop working in that area. Do not recreate the record by hand yet — a duplicate makes any later recovery messier.
2. Check Trash yourself, if you have it. Filter by Deleted by (you), narrow the date range to today, and look for the title. If it is there, preview it, confirm it is the right one, and restore.
3. If you cannot find it, contact your administrator straight away. Do not wait to see whether it matters.
4. Give them, in one message:
   • the kind of record (the name of the list or screen it lived on)
   • the record's title, or your best recollection of it
   • the # number from the delete confirmation, if you noted it
   • roughly when you deleted it — the date and the time to the nearest few minutes
   • your own name, as the account that did it
   • whether you deleted one record or a selection, and roughly how many
   • what has already been done since (anything recreated, any related records edited)
5. Ask two specific questions: whether the record can be restored, and if not, whether anything from it can be read back out of the application's logs so you can retype it.
6. Then check what else broke. A restore from Trash puts the relations back, but not the record's attached files or tags. A record that was deleted for good and rebuilt by hand is a new record, so every field that used to point at the old one is still empty. Use the checks in Checking What Depends On A Record in reverse: look at the records that used to point at it and set the field again.

Tips And Gotchas

• The Delete entry looks identical whether or not you have a recycle bin. Nothing on the confirmation tells you which behavior your application uses. Find out once, from your administrator, and remember it.
• Note the # number before confirming. It is the single most useful thing when asking for a record back, and unless you have Trash there is no way to look it up afterwards.
• Message strips vanish after about five seconds and are not kept. If you deleted several records and want to know what happened, refresh the list rather than trying to read the strips.
• A deleted record's link stops working. Anyone who bookmarked it, or has it in an email, either lands on an "Object not found" message saying the record may have been deleted or that they may lack rights — the two cases are indistinguishable from that wording — or is quietly returned to the list they came from, with no message at all.
• The Title column in Trash is sometimes blank. For some record types the title is calculated rather than stored, and the fallback the Trash screen uses is cleared when a record is deleted. Filter by Type and by the deletion time instead, and use the preview to identify the record.
• Trash may show you deleted records you would not normally see. Where your access to a record type is limited to certain records, that limit is not applied to the Trash listing. If that looks wrong for your organization, mention it to your administrator.
• You cannot empty Trash yourself. There is no "empty trash" button and no way to remove an item for good from this screen. Once an item passes ninety days it stops being listed and stops being restorable here; whether anything eventually clears it out behind the scenes is a question for your administrator.
• Duplicating before deleting is a cheap insurance policy. If you are about to delete something you are only fairly sure about, run the Duplicate action first and save the copy: you keep the field values, at the cost of one extra record to tidy up later. The copy does not carry the original's comments or its history.
• Exporting first is better insurance for bulk deletions. Before deleting a filtered set of records, export that list to a spreadsheet. It will not restore anything by itself — there is no spreadsheet import — but it preserves what the values were. See Action Buttons And Exporting.

What To Ask Your Administrator For

• "Does deleting in our application put records in a recycle bin, or remove them for good?" Ask once; the answer applies everywhere.
• "Can we turn the recycle bin on?" It requires both a setting change and, for the Trash screen itself, the feature being enabled for your application.
• "Can I have access to Trash?" Separate from the above, and granted per role.
• "Please add a status or active field to [record type] so we can retire records instead of deleting them," with the values you want and how the saved views should filter.
• "Please take delete off my role for [record type]," if the risk outweighs the convenience. Removing the permission removes the button.
• "Please block deleting [record type] once it reaches [state]," if there is a business rule that should be enforced rather than remembered.
• "Can you find out what happened to [record], deleted around [time] by [person]?" Include the # number if you have it.

Related Chapters

• Record Detail Screens
• Creating And Editing Records
• Selecting Records And Bulk Actions
• Roles, Groups And Permissions
• What To Ask Your Administrator For