Ask HN: Should I let clients delete their data? | Hacker News Reader

Ask HN: Should I let clients delete their data?

2 pointsrob0019 comments

For a SAAS product i'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.

The reason I thought of doing this is in case a support request coming through along the lines of "i deleted this by mistake, please help". 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.

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't request a deleted record to be restored after a certain period of time, the record can actually be deleted (via an automated process).

View on HN

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.

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.

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.

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

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

For Laravel: https://laravel.com/docs/5.3/eloquent#soft-deleting

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

There is a popular Ruby gem which addresses this sort of concern: 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.)

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)?

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.

Reply on news.ycombinator.com