Trash, archive & data recovery

Three ways data leaves your view

FlowQi never makes it easy to lose data by accident. Records like contacts and projects move through up to three reversible states before anything is gone for good. Understanding the difference matters: only one of them is permanent.

You might ask how to delete, remove, undo, recover, or restore something — in FlowQi that means archiving, the Trash, or permanent deletion. Only permanent deletion cannot be undone.

State	What it does	Reversible?	How to undo
Archived	Sets the record’s status to archived. It’s hidden from the normal lists and locked against edits, but it still exists.	Yes	Turn on Show archived to surface it, then Unarchive
Trash (soft-delete)	Marks the record as deleted (`deletedAt`) and moves it to Trash. It disappears from every normal view but the data is intact.	Yes	Open Trash and Restore
Purged (permanent)	Permanently removes the record from Trash. The row is deleted from the database.	No	—

Trash (soft-delete)

Deleting a record doesn’t destroy it. FlowQi soft-deletes it: the record gets a deletedAt timestamp and a record of who deleted it, then moves to Trash. It’s gone from every normal view, but the underlying data is untouched and fully recoverable.

Restore

From Trash you can Restore a record. This clears its deletedAt marker and returns it to its lists exactly as it was. Restore works on single items or in bulk.

Purge (permanent)

Purge permanently deletes a record that’s sitting in Trash. This is the only step that actually destroys data — the row is removed from the database and cannot be brought back.

Purging cannot be undone. To prevent mistakes, FlowQi asks you to confirm: for a single record you type its exact name, and for a bulk purge you type a confirmation phrase like delete 5 items. If what you type doesn’t match, the purge is aborted and nothing is deleted.

Who can do what — permissions

Lifecycle actions are gated by permissions, which are bundled into roles . FlowQi’s default roles include Super Admin (owner-level access across the account), Team Admin (manages a team and its data), User, and Guest User. There is also an internal System Admin role, reserved for FlowQi.

Each lifecycle action has its own permission, and for many of them the permission comes in three scopes — own, team, and all — so you can let people recover their own data without handing them account-wide reach:

Action	Permission	Scopes available
Archive / Unarchive a contact	`contacts.archive`	own · team · all
Delete a contact (to Trash)	`contacts.delete`	own · team · all
Restore a contact from Trash	`contacts.restore`	own · team · all
Purge a contact (permanent)	`contacts.purge`	own · team · all
Purge a project (permanent)	`projects.purge.all`	all only
Purge a task (permanent)	`tasks.purge.all`	all only

A few rules worth knowing:

Purge is the most restricted action. For projects and tasks, the permanent-delete permission only exists in the account-wide all scope — there’s no own or team purge for those, so permanently destroying a project or task is reserved for people trusted with account-wide access (in practice, a Super Admin).
Scopes narrow reach. A Team Admin granted, say, contacts.restore.team can recover contacts belonging to their team but not the whole account. The same action with the all scope reaches every record.
Super Admin has full access across the account and can perform every lifecycle action, including purge.
The last Super Admin is protected. FlowQi won’t let you remove or downgrade the final Super Admin in an account — at least one is always required (“At least one Super Admin is required for this tenant”). This keeps a workspace from ever being locked out of its own governance controls.

Archiving, deleting and restoring are everyday actions and can be scoped down to own or team. Purging is deliberately heavier — and for projects and tasks it’s account-wide only.

The audit log — who did what

Every governance-sensitive action is recorded in an immutable audit log, so there’s always a clear answer to who did this, and when. This gives you accountability and the context you need to recover confidently from a mistake.

Each audit log entry captures:

Field	What it records
Actor	The user who performed the action
Tenant	The workspace (account) the action happened in
Entity type	The kind of record affected — contact, organization, circle, project, task, or user
Entity ID	The specific record affected
Event	The action that happened (see below)
Metadata	A flexible JSON snapshot with the details — for a purge, this is a copy of the record taken before it was destroyed, so the evidence survives even though the row is gone
Timestamp	When it happened (created and updated times)

What gets logged

The audit log covers the full data lifecycle and the most sensitive admin actions. Events are named in a clear, consistent pattern, for example:

Contacts & organizations — created, updated, deleted, restored, purged, archived, unarchived (plus changes to emails, phones, addresses and links).
Projects & tasks — purged. Because a permanent delete leaves nothing behind on the record’s own timeline, the purge is recorded here in the audit log instead, so the permanent record of it survives.
Users — archived, deletion scheduled, and deleted, including details like how owned projects and tasks were transferred.

For a purge, the metadata holds a snapshot of the record as it existed just before deletion. That means even though purging is permanent, the audit log preserves a full account of what was removed, by whom, and when — exactly the context you’d want if you ever need to reconstruct what happened.

Roles & permissions — how roles bundle permissions and how access is assigned
Managing contacts — archiving and statuses on the CRM side
Projects — the project lifecycle