Is okay to only sometimes delete a model?

Question

I'm developing a sort of CMS. In it, users can create "Customers". For whatever reason, a user might want to delete that Customer. Maybe because the Customer was created in error, or maybe they think the Customer will never return again, or maybe they're just OCD and want a nice clean system.

However, Customers are referenced in various places throughout the system. For example, Bookings link to Customers. If a Customer is linked to a Booking and then later deleted, then the Booking will essentially be corrupt. It's now missing a vital piece of historical information. To prevent this, I've created foreign key constraints at a database level.

Here's what I'm thinking: I can leverage these constraints by attempting to delete the Customer when requested, but upon failing perform a soft delete instead. This way I can maintain referential integrity but also prevent cruft build up from soft-deleted Customers that aren't actually used anywhere.

To recap:

1. If a Customer is not referenced anywhere in the system, it will perform a real hard delete
2. If the Customer is referenced somewhere, it will perform a soft delete (i.e. flag the record as deleted but keep it)

Is this okay? My concern is that you don't really know what the "Delete" button will do until you press it, but from a user's point of view it doesn't really matter -- either way the Customer will disappear from the index. Are there other issues?

Answer 1

From the usability point of view, it's essentially the same for the user whether soft or hard delete is used: the record is gone.

This isn't the absolute truth, however, if the deleted Customer can be accessed via the Booking it is linked. It's something that needs to be planned for, e.g. is it ok to just show the Customer without full functionality to interact with it.

I'd say that for most systems the norm is to never actually delete records, but only to hide them with a flag like your idea was. Even the big players like Google and Facebook never actually delete anything.

Answer 2

This doesn't really seem like a UX question, because from the UX perspective the customer cannot tell the difference.

But if it helps, from a system design perspective, allowing a relationship dependency to dictate your data keep/delete policy isn't a good design practice (it's allowing the "tail to wag the dog"). Do it for expediency if you don't have time to write delete propagation right now, but in the long run I think you are better served by figuring out what policy is right for the business and then writing the delete (or soft delete) logic accordingly. Partial deletes may be expedient but they come with their own costs (eg managing irregular/inconsistent data scope).

The business decision may depend, among other things, on the cost of storage, customer privacy, and your internal analytics needs (eg time series or behavioral analysis is hard to do if you delete the data). Just note that privacy can be managed if you want to keep the records... You can anonymize customer data on soft delete, for example.