
Ask HN: Should I let clients delete their data? - rob001
For a SAAS product i&#x27;m building I was wondering how to handle data deletion.  When a user clicks to delete a record, should I actually remove that record from the database, or should I flag it for deletion, so that the record no longer shows, but it is retained.<p>The reason I thought of doing this is in case a support request coming through along the lines of &quot;i deleted this by mistake, please help&quot;.  In this case, changing a field in the table would be much easier than restoring a backup and then writing a script to put the data back into the live database.<p>Is this a good approach?  An alternative to having a delete flag would be moving records to a deletion table, but that seems more work.  Obviously, if a client doesn&#x27;t request a deleted record to be restored after a certain period of time, the record can actually be deleted (via an automated process).
======
abricot
I think it is important to allow users to delete data in case they are 1.
wrong or 2. at the end of their lifecycle.

But it is also important to treat deletion carefully. Depending on the data,
there might be a need for an audit trail for deleting data (which mostly would
mean that you only mark it as deleted, so you can later see who deleted it and
what was deleted).

You might also allow normal maintainers to mark things as deleted, and then
only allow specific access levels at the individual customer to see the
deleted data. Everything should be accessible by the customer.

I suggest that you think carefully before requiring yourself or anyone in your
support to be responsible for data maintenance. This opens up for a lot of
extra work, and confusion about who has access to the data as part of their
daily work.

------
hakanderyal
Depends on the problem domain, but flagging the records when user deletes
them, and notifying the user that the action is reversible for x days, and
allowing them to delete the record permanently if they want is a sensible
approach.

------
brudgers
Suppose the button is labeled "delete in thirty days". Then the dashboard
could show data scheduled for deletion.

Hmm...even better might be allowing the user to establish their own deletion
policy. And establishing policies for the SAAS company regarding recovery and
recovery, if it is available, is another service that the SAAS company could
charge money for...though I am probably assuming a B2B model.

Anyway, my primary recommendations are:

1\. Be clear what the company is actually doing.

2\. If the user has control of the data policy, then let them tune the policy.

Good luck.

~~~
afarrell
3\. Pick a default that is safe for users in the 75th percentile of
carelessness.

------
saluki
Typically you and your users are rarely going to say "I wish this data had
been deleted" you will run in to situations where you and your users will say
"I wish that wasn't deleted" I rarely design an app to delete anything.

Soft Deletes are pretty standard in development and I would recommend going
that route unless sensitive data is involved and there is a reason to worry
about data being retained as a bad thing.

For Rails:
[https://github.com/rubysherpas/paranoia](https://github.com/rubysherpas/paranoia)

For Laravel: [https://laravel.com/docs/5.3/eloquent#soft-
deleting](https://laravel.com/docs/5.3/eloquent#soft-deleting)

~~~
rob001
Ah, soft deletes, so there's an accepted term for this approach. Does anyone
know what sort of books run through these sorts of development issues? I feel
like I should plug a few gaps in my knowledge around this area

------
patrickgordon
There is a popular Ruby gem which addresses this sort of concern:
[https://github.com/rubysherpas/paranoia](https://github.com/rubysherpas/paranoia)

Essentially it doesn't delete but gives the impression to the user that it
deletes. I like this idea because it really does guard against mistakes.

I'm not sure if you have an ethical/moral concern with retaining data that a
user thinks is deleted but that's another thing altogether (Personally, I
don't.)

------
cakes
It potentially depends on the data and volume of deletions (and maybe other
factors). How hard is it for users to recreate? If you select 30 days what
happens on day 31 when a user "just gets back from vacation" (or similar)?
Maybe deletion should be hard enough (e.g. Trash Can + Dialogs) that
requesting a restore isn't something you'd have to do (except, maybe, in
extreme cases)?

------
borplk
It is fairly standard practice to mark for deletion and communicate on the UI
to the user that their data will be deleted in X days. Also doesn't hurt to
spell that out in terms of service and privacy policy.

