Data management
Scopingly gives you reversible ways to remove content (the recycle bin and archive) and thorough, complete ways to delete it (document and organization deletion). This page explains what each does, who can do it, and how long things are recoverable.
PRD recycle bin (soft delete)
Deleting a PRD sends it to a recycle bin rather than destroying it. A deleted PRD is hidden from every normal view but is restorable for 30 days.
- Restore. Within the 30-day window, the PRD can be restored to the working list, unchanged.
- After 30 days. Your organization's retention policy decides:
- Retain (the default) — the PRD is kept but stays hidden forever, preserving an audit record.
- Purge — a background reaper permanently deletes PRDs whose window has elapsed.
- Permanent delete. You can permanently delete a PRD immediately, bypassing the window, when you're certain.
Soft-delete, restore, and permanent-delete require the PRD owner or an org admin. The recycle bin shows an owner their own deleted PRDs and shows an org admin the whole organization's bin.
Approved PRDs can't be soft-deleted
An approved PRD represents a finalized decision and must be retained for history. Deleting one is blocked — archive it instead (below).
PRD archive
Archiving a PRD is for keeping history rather than removing content. An archived PRD leaves the default working list but stays readable and searchable.
- Archive state is orthogonal to approval status — archiving an approved PRD keeps it approved.
- Archive is allowed for the PRD owner, a team owner of the PRD's team, or an org admin.
- Unarchive is allowed for a team owner or an org admin only — deliberately not the plain PRD owner, so archived history isn't casually reopened.
- While archived, a PRD is read-only; editing requires unarchiving first.
See PRDs for how archive and the recycle bin fit the PRD lifecycle.
Document & organization deletion
Deleting a document or an entire organization performs a thorough cleanup across every data store — PostgreSQL, MongoDB, the full-text search index, and the embeddings index all have the relevant data removed. There are no orphaned copies left behind in a derived index.
- Document deletion removes the document and its content synchronously, and the search and embedding indexes are cleaned asynchronously via events.
- Organization deletion removes the org and everything belonging to it, then triggers asynchronous cleanup of the search and embedding indexes for that org. Because content is encrypted per organization, destroying the org's key also renders any residual ciphertext permanently unrecoverable.
Governed organization deletion
So that a closing account's data can't linger, org deletion can be run as a request-and-approval flow rather than executed directly:
- Request. An org admin or owner can request full organization deletion. There is one pending request per organization at a time.
- Review. A platform app admin reviews the request and either approves it — which runs the irreversible purge on exactly the organization named in the request — or denies it.
- Cancel. The requester can cancel a request while it is still pending.
This separates requesting deletion (an org admin/owner can do it) from executing it (only a platform app admin can), so no single tenant actor can unilaterally erase an organization.
Calibration pool retention
If your organization opted into the cross-org calibration pool, the deletion request lets you choose what happens to your pooled contribution:
- Retain (default) — your already-anonymized, non-identifying contribution (effort ratios only, with no organization identity, content, or magnitudes) is kept so it keeps improving shared cold-start estimates for everyone.
- Erase — your contribution is fully removed along with everything else.
Either way, deletion erases your organization's identifiable data. The retain option only preserves learning that was already anonymous. The app admin sees your choice before approving.
The org owner controls direct deletion
A direct organization delete (outside the governed flow) is an owner-only action on the owner's own organization. See roles & permissions.