Trash & Test Data

Trash and Recovering Deleted Records

Almost everything in the platform soft-deletes rather than genuinely deleting. Trash is where you find those records and put them back.

Where to find it

Architect Panel → Data:

• Trash — the console — find and restore deleted records
• Record Retention — the one place deletion is permanent

Why deletion is usually reversible

A user deleting the wrong record is common, and irreversible deletion turns a moment's inattention into lost work. Soft deletion means the row is hidden rather than removed, so it can be restored.

Finding it

Trash discovers deleted records across datastores rather than requiring you to know where to look — which matters, because the person asking for a recovery usually describes what the record was, not which datastore held it.

What restoring does and does not do

Restoring returns the record. It does not automatically restore relationships that were themselves deleted, so a deleted parent restored on its own may come back without its children unless those are restored too.

Check the related records after any restore that matters. This is the common surprise.

The one exception

Retention disposal genuinely destroys. That is the point of it, and nothing in Trash can bring back a disposed record — which is why disposal sits behind three separate switches.

Trash is for accidents. Retention is for policy. They are different mechanisms and only one is reversible.

Trash is not a retention strategy

A soft-deleted record still exists. It is still personal data, still in every backup, and still discoverable in a subject access request. "We deleted it" is not true of a soft delete, and saying so is a misstatement worth avoiding.

If data should genuinely be gone, that is retention's job.

Worked example

A caseworker deletes the wrong referral. The team leader opens Trash, finds it by name and date, and restores it. The attached documents were not separately deleted, so they reattach. Total elapsed time about a minute, where previously this was a support call and a database restore.

Recommendations

• Restrict who can empty or permanently remove. Restoration is safe; the opposite is not.
• Check related records after a restore.
• Do not treat Trash as deletion when answering a data protection request.
• Investigate repeat accidental deletions — usually a confusing button rather than a careless person.

Sample Data and Resetting an App

An empty datastore hides problems. Sample data fills one with realistic rows so you can see how it actually behaves.

Where to find it

Architect Panel → Data:

• Sample Data — the generator, and the reset that undoes it
• AI Builder — where a new structure is usually created

Why generate data at all

Layout, validation and performance problems are invisible on an empty form and obvious with fifty rows in it:

• Columns too narrow for real values.
• A browse view that looks fine with three rows and unusable with three hundred.
• Dropdowns that should have been searchable.
• A dashboard block that takes four seconds once there is history behind it.

Building against an empty system and discovering these after go-live is the normal way a rollout goes badly.

Generating

The generator creates plausible values for the field types it finds — names, addresses, dates, numbers, selections — so the result looks like data rather than "test1, test2, test3". That matters: realistic values expose layout problems that placeholder text does not.

Resetting

The reset removes application data and returns the app to an empty state. That is what makes generating freely safe — you can fill it, look at it, adjust, refill.

Understand precisely what the reset clears before running it. It is designed for a development or pre-launch instance. On anything holding real data it is exactly as destructive as it sounds.

Never generate into production

Generated records are indistinguishable from real ones to everybody except the person who generated them. Once mixed into live data they are very hard to remove reliably, and they will appear in reports, counts and returns.

Worked example

A team builds a new inspections datastore. Before rolling it out they generate 200 sample inspections, which immediately shows that the browse view needs a date filter and the notes column is far too narrow. Both are fixed, the data is reset, and the real rollout starts on a form that has already been used in anger.

Recommendations

• Generate before you demonstrate. A demo on empty screens shows nothing.
• Never generate on production.
• Read what the reset clears before you run it, every time.
• Generate enough to be realistic — twenty rows will not reveal a performance problem.