I work on a complex and heavily data-backed app (essentially an ERP) that has a number of different objects in the system that track real objects in the world. Users can create objects which later have actions performed on them, which mirror real world actions.
Most of the objects can be archived and deleted.
Generally speaking, archiving is useful in situations where the object has lived its useful life. Archiving gets the object out of the main UI but keeps its history, which is critical for historical tracking. Archived objects are accessible via either an archived tab or explicitly filtering for archived objects, which is important for auditing purposes. Un-archiving archived objects is always possible.
Deleting is used primarily in situations of incorrect data entry — the attributes on the object were entered wrong, for instance. And in fact it is not possible to delete objects that have history on them as there are then data dependencies that prevent it. Deleted objects are gone forever from the system.
The question is: for brand new objects (no history) should we allow archiving or disable it and only allow deleting?
We haven't come up with any compelling use case for archiving an object with no history.
We're debating between two approaches:
Consistent behavior. Showing and allowing archiving on unused objects, while not obviously useful, reveals how the system works and allows users to understand the feature from the minute they create an object. There is no "state" to worry about or confuse people — no new button that shows up later on that object, and no confusion about when you can archive and when you can not.
Simplifying the UI. Without a use case, showing and allowing this feature is clutter and adds to users' cognitive load.
How can we decide which approach is better? Best practices, or strategies to answering this question?