In speaking with several hosting clients, I have noticed several confusions and opportunities for improving UX around deaccessions.

1. Particularly for governmental and corporate repositories, they would like a more robust, configurable audit trail to document if archival objects have been edited and and deleted.

2. There is a Deaccession option in the Event drop-down list which logically seems like a path towards making a Deaccession record. However, it does not function or index like the Deaccession record that you can access via a Accession or Resource record. Either remove this option from the Events drop down menu or link to the Deaccession module from this selection.

3. There seems to be an unnecessarily rigid current relationship between linking Deaccession records with either Resource Records or Accession records. My opinion is that it should be an agnostic action record that could be linked to either or all (Resource, Accession, and Digital Object)

4. There is confusion when a Deaccession record can only be accessed on a Resource record from the top/collection-level record. Some users would think that it would make more sense to be able to open the Deaccession record from the actual archival object that they are about to delete. Ideally, this would behave like so:

   1. Staff user clicks on archival object (item or series)

   2. There is a button to deaccession which opens up the current Deaccession record fields. Once the staff user fills out these fields, the archival object is deleted and the deaccession record is automatically generated to attach to the top/collection-level record with an automatic record of the user who did it in ArchivesSpace.

   3. This deaccession record automatically compiles all supplied information about the deleted record and the staff user supplied data.

   4. These deaccession records should be reportable, with configurable options for pulling it from Resource Records and/or Accession records