Kiravy/ Docs
Log inGet started

Archive & delete

Archive (reversible) vs delete (not); 7-year retention guidance.

Three actions live in the danger zone. Two are reversible. One is not.

This page covers what each does, who can do it, and how Malaysian retention rules (7-year FRD compliance) shape the design.

Where it lives

The danger zone sits at Client → Settings → Danger zone for each client. Only Partner and Manager roles can access it; the section is hidden for Senior, Junior, and Viewer.

There's also a future firm-level danger zone (delete entire firm) reserved for Partners — that flow isn't UI-exposed yet; support handles it manually.

[Screenshot pending] Client → Settings → Danger zone showing the Archive, Restore, and Delete sections separated by red dividers

Archive (the right answer 95% of the time)

When an engagement ends — client moves to another firm, business closes, you stop doing their books — archive, don't delete.

What archive does

WhatResult
Client visibilityHidden from the default Clients list
Client data (transactions, receipts, invoices, AI history, integrations)All preserved, fully intact
Per-client RLSStill enforced — only previously assigned users would see it if they pulled up the archived view
Sync from SQL AccountStops (links to .FDB stay in DB but no further pulls)
AI assistant for this clientDisabled (the client is in dormant state)

Who can archive

Partner or Manager.

How

  1. Settings → Danger zone → Archive client
  2. Single confirmation dialog
  3. Done — instantly archived

How to see archived clients later

Clients list → switch the Status filter from Active to Archived or All. Archived rows show greyed out with an Archived badge.

Restore

Archiving is fully reversible:

  1. Find the archived client (filter as above)
  2. Open the client → Settings → Danger zone → Restore client
  3. Confirm

The client returns to active status with all data, integrations, and assignments unchanged.

Delete (only when you're sure)

Irreversible. Cascades to every child row: transactions, receipts, engagements, documents, portal users, AI conversations, audit logs, AR / AP invoices, customers, suppliers, integration links.

When to use it

Realistically: almost never. Reasons that justify it:

  • Test client you created to try the product, never had real data
  • Duplicate entry created by mistake (e.g. created Mamak Pelita twice)
  • PDPA / GDPR purge request where data must be removed in entirety

When NOT to use it

  • End of engagement — archive instead. You'll thank yourself 5 years later when LHDN asks.
  • Cleanup of older clients — archive. Storage is cheap; lost audit history is expensive.

Malaysian record retention. Books and supporting documents for a tax year must be kept for 7 years after the year of assessment (Income Tax Act 1967 s. 82A). Deleting a client whose books you handled inside that window violates retention. Archive is the safe default; delete only when you're certain there's no audit trail to defend.

How (the deliberately frictional flow)

  1. Settings → Danger zone → Delete client permanently
  2. A red modal appears showing what will be destroyed (counts of transactions, receipts, etc.)
  3. Type the exact client name into the input
  4. The Delete button stays disabled until your typing matches
  5. Final click

The friction is intentional — this is the one place we'd rather you accidentally cancel than accidentally proceed.

Who can delete

Partner only. Managers can archive but not delete. This is enforced at the database — RLS policies refuse the operation for non-Partners.

What about backups?

For permanent deletes, Kiravy keeps point-in-time database backups at Supabase for 7 days. If you realised within a week that you deleted the wrong client, contact support — we may be able to restore from backup. After 7 days, the data is gone.

This isn't a guarantee — backups are for disaster recovery, not undo. Treat deletion as final.

Audit log

Every archive / restore / delete is logged in audit_logs:

  • Who did it (user_id)
  • When (created_at)
  • What was affected (target_table, target_id)
  • Action verb (archive_client, restore_client, delete_client)

The audit UI is planned (Partner-only); for now, support can pull the trail on request.

Firm-level deletion

To delete an entire firm workspace (e.g. closing the practice):

  1. Contact support
  2. We confirm in writing
  3. After the 7-day cooldown, the workspace and everything in it is purged

There's deliberately no self-service button for this. The blast radius is too large to make casual.

Common scenarios

"Client just retired, we're winding down their books"

Archive after final filings. Restore briefly if LHDN audits later.

"We accidentally created the same client twice"

Identify which has real data (probably the older one). Delete the empty duplicate. Confirm by typing its name.

"Client requested data deletion (PDPA)"

  1. Confirm the request in writing
  2. Delete the client (Partner)
  3. Tell support to also scrub backup tapes after the 7-day window
  4. Send the client written confirmation

"We're switching from Kiravy to another platform"

Don't delete. Export your data first (CSV exports from each tab, PDF P&L reports per period), then either keep your Kiravy subscription dormant for the retention window or contact support for a full data export.

What's coming

  • Audit log UI for Partners
  • Bulk archive for clean-up at year-end
  • Data export package — one button generates a ZIP with all CSVs, PDFs, and receipts for a client
  • Self-service firm deletion with a 30-day grace period

What's next