Why should you be able to Delete your data?

Because data you can't delete is data you never really owned. A business collects customers, suppliers, staff accounts and years of documents, and sooner or later a day comes when some of it has to go: a branch closes, a company is sold or wound up, a test account was filled with real names, or a law says a person's details must be erased. If the software can only hide records, or leaves copies in places nobody thinks to look, then "deleted" means "still there, and still your problem". A delete you can rely on takes everything, takes it once, and tells you plainly what it can't reach.

Why deleting matters

• The law may ask for it. Many countries give people and businesses the right to have their personal data erased, and say how quickly. Whether and when it applies to you is for you and your advisers: no software can decide that for you. What the software can do is make sure that when the answer is "delete it", it can be done.
• Data you don't hold can't leak. Every record kept past its use is a record that can be stolen, subpoenaed or mislaid. Fewer records is less to lose.
• Leaving has to be possible. Getting your data out is one part of owning it (see importing and exporting). Having it removed from the system you've left is the other.
• Mistakes need a way out. A tenant set up to try the software, or a branch made by accident, shouldn't sit in the system for ever.
• A delete that leaves copies isn't a delete. A customer's name also turns up in a message, a file, a history entry and a dashboard. Erasing the customer's row and leaving those behind only looks tidy.

What deleting a tenant means

A tenant is a company's own space in RPM: its customers, suppliers, stock, quotes, orders, invoices and every other document, its books, its files, its messages, its history and its dashboards. Tenants sit in a tree. A company has a top tenant, and may have branches beneath it, and branches of branches.

Deleting a tenant deletes that tenant and everything in it. It also deletes the accounts of the people who work only there. People who also work in other tenants keep their accounts, and lose only their link to this one.

It is not a tidy-up or an archive. There is no recycle bin, no grace period and no undo: once a tenant is deleted, RPM can't bring it back, and neither can you.

What happens, in order

1. You confirm with the tenant's code typed out and a one-time code (more below).
2. The tenant closes at once. Everyone signed in to it is signed out, and nobody can sign in to it again. Its imports and exports stop.
3. The Platform Team is told that the tenant is being deleted.
4. Its records are erased, in the order their dependencies need: documents before the things they point at, the tenant itself last. Its files and its dashboards go with them.
5. The Platform Team is told again when it is done, or if it failed. A failed delete is picked up and tried again; you don't have to start over.

How long it takes depends on how much the tenant holds. In the user guide the branch has left the list within moments.

What the delete doesn't reach

Being straight about this matters as much as the delete itself:

• Backups and logs are not rewritten. They are kept for a short, fixed time and then removed, and a delete doesn't change that. If you need the schedule for a notice or an audit, ask us.
• Anything already outside RPM. Mail the system sent, files a person downloaded, a report somebody exported or printed. Those copies are the holder's to delete.
• The company's own notes about a branch. The top tenant's history records that it created the branch, and a message a branch user sent to the company is a message the company received. Those stay in the company's records until the company itself is deleted, and go with it.
• An account other records still name. If a record in another tenant names a person as the one who created it, the account can't simply vanish. It is kept as an empty shell: no name, no email, no password, no link to any tenant, and named only "Erased account".

What happens to the tenant's code

Every tenant has a code, such as FYNBOS-PRL. When a tenant is deleted, its code is retired for ever. It can never be used again, not for a new tenant, a new branch, or the same business starting over, and not in a different mix of capitals either. The check is made in the application and again by the database, so nothing, whether a sign-up, a branch saved on the Tenants screen or someone at a console, can slip it back in.

The reason is trust. A code appears on old invoices, in emails, in exports and in your accountant's files. If it could be handed to a different business, a stranger could one day look as if they were you. A retired code means that a code, once seen, always means the same business, or nothing.

RPM keeps one small record for each retired code: the code itself, when the delete was asked for and finished, and how many rows went. Nothing about the people or the business.

Branches go first, one at a time

A tenant can't be deleted while another sits beneath it. The Delete button on the top tenant stays greyed out, and names the branches in the way. You delete a branch, then the one above it, then the one above that: children first, then parents, each with its own confirmation.

This is deliberate. Each confirmation names exactly one tenant, so one slip can't take a whole tree, and each one is a pause in which someone can ask whether this is really the one they mean. The parent's data stays untouched while a branch is deleted: only the branch goes.

Who can delete a tenant

Only the founder: the person who signed the company up. That is the account that created the company's top tenant, and it may delete at any level of the tree. Other administrators of the company, even with every permission there is, are not offered the button at all. Neither is anyone else.

The founder has to prove it is them, at that moment, twice over:

1. Type the tenant's code, so the wrong tenant is never deleted by habit.
2. Enter a one-time code, either emailed to them or shown by their authenticator app. An emailed code works for ten minutes and for that tenant only: a code asked for one tenant is refused for another. Guessing is limited: an emailed code is spoiled after three wrong tries, and too many wrong authenticator codes pause the account's code step for a while.

A founder who deletes the tenant they are signed in to is signed out along with everyone else, and their account is deleted too if it belongs to no other tenant.

How RPM does it

In the side menu, open Tenants. Open the branch, click Delete tenant, and the dialog asks for the code and the one-time code. Every step has a picture on a desktop browser and on an Android phone, in the Delete a tenant page of the user guide. Those pictures are taken by RPM's own end-to-end test, which deletes a tenant on a real server, with a real emailed code, and then checks that nothing of it is left in the database. They are pictures of the real thing, not a mock-up.

RPM doesn't do these yet:

• A count of what will go. The dialog says what kinds of records are removed, but not how many of each.
• A cooling-off period. A confirmed delete starts at once. There is no 24-hour window to change your mind.
• A certificate. The Platform Team is told, and the retired code is kept, but RPM doesn't yet issue a document saying a tenant was erased.
• Erasing one person across everything. This deletes whole tenants. It doesn't hunt for every mention of one customer or one person inside a tenant's records, history and files.

If you need help

Deleting is for the day you're sure. If you're not, or you don't know who your company's founder is, or you can't reach the founder's account, or a delete you started doesn't seem to finish, contact RPM before you do anything else: write to support@rpmcode.com. We can tell you what a delete would cover, and we'd far rather answer a question than be asked to undo a delete that can't be undone.

See it in under two minutes

Play the 88-second video