Ask HN: Should I let clients delete their data?

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.

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

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.