How Should a SaaS App Handle Account Deletion?

How Should a SaaS App Handle Account Deletion?

Make it findable, make it honest about what will be destroyed, let the person take their data first, and then actually delete it. Most products fail on the second and fourth. They hide the button, use vague language about what goes, and then quietly deactivate instead of deleting.

Deletion is the part of a product nobody demos and everybody eventually needs. It is also one of the few interface decisions with a direct legal dimension, which makes vagueness expensive rather than merely rude.

Here is how we would design it, and the rules that constrain the design.

What Are You Actually Required to Offer?

Under the GDPR, erasure on request in defined circumstances. Article 17 gives a data subject the right to have personal data erased "without undue delay" where, among other grounds, "the personal data are no longer necessary in relation to the purposes for which they were collected", consent is withdrawn with no other legal basis, or "the personal data have been unlawfully processed."

The right is not unlimited. Article 17 sets out exceptions where processing is necessary for freedom of expression, for compliance with a legal obligation, for public health, for archiving and research where erasure would "render impossible or seriously impair" the objectives, or for the establishment or defence of legal claims.

There is also an obligation people forget. Where the data has been made public, the controller must "take reasonable steps, including technical measures, to inform controllers which are processing the personal data" of the erasure request. Deletion does not stop at your own database.

Does the Requirement Apply If You Are Not in the App Store?

The legal position does not depend on a store, but Apple's rule is a useful benchmark for what good looks like. Apple states that "starting June 30, 2022, apps submitted to the App Store that support account creation must also let users initiate deletion of their account within the app."

Two parts of Apple's guidance are worth adopting regardless of platform. Apps "should not require people to make a phone call, send an email, or go through other support flows", and "all users should be allowed to delete their accounts, regardless of where they're located." Geography should not decide whether someone can leave.

The third part is the one products most often violate. Apple is explicit that "only offering to temporarily deactivate or disable an account is insufficient." A deactivation labelled as deletion is not deletion, and calling it one is the kind of thing that ends up in a regulator's example.

Where Should the Delete Option Live?

In account settings, at the bottom, findable by searching the word delete. Not in a help article, not behind a chat widget, and not three levels into a billing flow. A user who cannot find it will either contact support or write a review, and both cost more than the button.

Do not use a visually alarming treatment as a substitute for a clear explanation. A red button surrounded by warning icons reads as a dark pattern when the copy beside it is vague. Plain language and a normal button with a clear confirmation is both kinder and more defensible.

Distinguish deleting an account from leaving a workspace, because in multi tenant products those are different actions with different consequences. A user who leaves a team has not deleted their personal account, and a user who deletes their account may be the only owner of a workspace other people rely on.

What Should the Confirmation Screen Say?

Exactly what will be destroyed, exactly what will survive, and whether it can be undone. Apple's framing is a good baseline: deletion should "offer to delete the entire account record, along with associated personal data", and removes "any data associated with the account that the developer isn't legally required to maintain."

That last clause is the one to surface. If you keep invoices for seven years because tax law requires it, say so on the confirmation screen. Users are generally fine with a legal retention requirement and extremely unhappy to discover one afterwards.

List the consequential effects too. Shared documents that will disappear for colleagues, integrations that will stop, scheduled work that will not run. These are the things that make a deletion regrettable, and nobody can weigh them if they are not shown.

Should You Offer an Export First?

Always, and on the same screen rather than in a different part of settings. Somebody deleting an account is the person most likely to want their data, and making them go and find an export flow after they have already decided to leave is a poor last impression.

Make the export complete and in a format somebody can actually use. A JSON dump of internal identifiers technically satisfies a portability request and helps nobody. CSV for tabular data and original files for attachments is the version people can open.

If the export takes time to generate, say so and do not block the deletion on it. Queue the export, confirm the deletion, and send the file. We covered the mechanics of this in our piece on import and export UX.

Is a Grace Period a Good Idea or a Dark Pattern?

A good idea if it is short, clearly stated, and genuinely ends in deletion. A grace period protects people from a slip in a way nothing else does, and account deletion is exactly the kind of irreversible action where a slip is catastrophic.

It becomes a dark pattern when the period is long, when it is not disclosed at the point of confirmation, or when the account quietly stays alive after it. Thirty days with a clear statement and a real deletion job is protection. Ninety days hoping the user comes back is retention dressed as safety.

Whatever you choose, disclose it in the confirmation and in the confirmation email. "Your account and data will be permanently deleted on 26 October" is a sentence that does all the necessary work.

What Does Deletion Mean in Your Backend?

More than a flag on a row. Real deletion has to reach backups, analytics pipelines, email platforms, data warehouses, support tools, and any vendor you have shared the data with. That last category is where most products silently fail.

Write down every system that receives personal data before you design the flow, because the deletion job is only as complete as that list. A deletion that clears your production database while leaving the person in your email platform is not a deletion, it is a partial one that will send them a newsletter next Tuesday.

Backups deserve an explicit policy rather than an exception. It is generally accepted that you cannot surgically edit a backup, so the workable answer is a defined backup retention period, a documented process that re-applies deletions on restore, and a plain statement of both.

What Should Happen to Shared and Collaborative Data?

Decide per object type and tell the user before they confirm. A comment a person wrote on a shared document is their personal data and also part of a record other people rely on. Deleting the account can remove it, anonymise it, or transfer it, and each answer is defensible.

Anonymising is usually the least disruptive: the comment survives with the author replaced by a neutral label, and the thread still makes sense. Full removal can leave conversations unreadable, which harms people who did not make the deletion request.

Ownership transfer needs a designed flow, not an error message. If the person is the sole owner of a workspace, the product should offer to hand ownership to a named colleague before proceeding. We wrote about the surrounding model in our piece on roles and permissions UX.

What Should You Send Afterwards?

One email confirming the deletion, and then nothing. The confirmation should state what was deleted, what was retained and why, and the date any grace period ends. It should not include a reactivation offer, a discount, or a survey.

Make sure the suppression actually holds. The most common failure after a deletion is a marketing email arriving weeks later because the person's address survived in a different system. That single message undoes whatever goodwill the clean deletion earned.

If you want feedback about why they left, ask on the way out rather than afterwards, and make it optional and skippable. A one question optional field on the confirmation screen gets better answers than an email to an address you are supposed to have deleted.

Where Should a Team Start?

By trying to delete their own account and timing it. Most teams have never done this on their own product, and the exercise usually finds a missing button, a support only path, or a deactivation pretending to be a deletion within ten minutes.

Then map every system the data reaches and turn that into the deletion job. That map is the real work, and it is also useful for a dozen other things, including the security questionnaires you will be asked to fill in.

If you are designing this part of a product and want a second pair of eyes on the flow or the copy, we are happy to help. Find us at phoenix.studio.