We’re diving into the Deaccession process for the first time and could use some guidance. Any chance someone could share a step-by-step guide or or shed some light on the best way to tackle this?
Currently I’m at step one - I’ve created a new Disposal and linked it with the required collection objects, but I’m not sure how to link it to an existing Accession, and more importantly how to make it visible and obvious that the collection objects in question are not any more available within our collection.
Your insights are much appreciated!
Our solution to indicating that items are no longer in the collection is to have a picklist on the collection object form that indicates ‘discarded,’ ‘donated,’ ‘lost,’ etc.’ near the catalog number. This isn’t automated or linked in any way to the deaccession forms, which we haven’t been using (so I can’t help you there, sorry) but may be a useful idea.
Is there any Specify guidance on this? I am particularly interested in ways that deaccessioned objects would be removed from data exports and reports? If there are any fields that could be used? I have used just a checkbox in the past, but also moved to a picklist like Paul mentioned above….
I’ve added a guide specifically covering all there is about Deaccessions today in response to community requests:
Paul’s method of defining a pick list for export filtering or searching is currently the most effective strategy I can think of. At this time, there is no ‘flag’ field indicating that a particular object has been deaccessioned. This is mainly because deaccessions are not directly linked to Collection Objects but rather to Preparations associated with an object.
I don’t believe there is a reliable way to exclude an object based on its relationship to a preparation if it has been deaccessioned. Therefore, indicating this via the Collection Object with a flag is something I recommend.
For instance, if you are exporting preparations using the GGBN Preparation Extension, you could exclude preparations that are unavailable due to being linked to a deaccession-adjacent interaction. You can do this by adding an additional filter to the query that excludes those linked to deaccession through any interaction.
If anyone has suggestions on the best approach, please let me know! Perhaps a virtual field that indicates whether any portion of material is deaccessioned, or a field that automatically flags if all preparations have been deaccessioned, would be necessary.
Thanks Grant, these insights are much appreciated! For my side, I think we haven’t yet started using all the different fields that can help serve this issue.
A virtual field like this would be ideal! I haven’t implemented the recording of deaccessions in our DB yet mainly for this reason-- no automatic way of seeing that some or all of the lot is deaccessioned is a problem.
This folds into the larger issue of allowing users more control over defining virtual fields, IMO. We really should be able to define and format fields based on calculations/conditions, beyond the extent possible with conditional forms at present.