Required to delete, not allowed to
The retention period has expired but proceedings are still running. Three mechanisms govern this, and they get confused constantly: the period says when, sealing says do not change, the hold says do not delete.
A document reaches the end of its retention period. The nightly deletion run would remove it, as intended and as the deletion concept requires. Except that proceedings are under way in which this very document plays a part.
Cases like this are why a document management system has not one protective mechanism but three. They get confused regularly, although they answer different questions.
Three questions, three answers
The retention period answers: how long must the object be kept? It comes from the deletion policy and sits on the object as an expiry date. Before that, the deletion run must not touch it at all.
Sealing answers: may the object still be changed? A sealed object is immutable; every attempt to change or delete it is refused.
A hold answers: may the object be deleted? It exempts the object from any deletion, independently of the retention period. Changing remains possible.
The short form appears like this in our documentation: the period says when, sealing says do not change, the hold says do not delete. The three do not exclude each other; they apply at different points.
Where the protection sits
A write protection that lives in the edit form is not one. It holds until someone touches the same record through bulk editing, the API or a console command.
So sealing sits in the data model. It therefore applies equally across every write path: interface, bulk edit, REST API, connectors, console. There is no way around it, including none for us.
Refused are changes to content and metadata, replacing the file, moving it to the recycle bin and permanent deletion. Two things remain possible: setting or lifting a hold, and lifting the seal itself, with a reason and under the four-eyes principle.
The attempt counts too
Every refused write or delete attempt on a sealed object creates a log entry, with person, time, affected fields and type of attempt.
That is not decoration. Without those entries it would stay invisible that somebody tried, and in case of doubt that is the more interesting information than the fact that it did not work.
Why a hold carries a case reference
A hold has a free field for the proceedings that triggered it, for instance the file number of a court or a supervisory authority. That sounds like a formality and is the difference between a traceable exception and an inexplicable one.
A hold without a reason cannot be resolved two years later: nobody knows whether the proceedings are still running, and nobody dares lift it. That is how stocks accumulate that stay forever out of caution, although the deletion concept says otherwise.
Off by default
Automatic sealing on approval can be enabled per object type, and it ships switched off. That is deliberate: until now an approved document was freely editable. An update that silently activates sealing would change established workflows, because a correction after approval would suddenly require unsealing with a reason.
Already approved existing records also stay untouched. Switching it on decides about future approvals, not retroactively about the past.
More on the document management module page.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.