Ressources

Resources & Remarks

This article is meant to offer the functional context for the technical implementations tagging and schema flow and is important as such.

•  If this page is published the Audit Trail - an "Object's History" page can be moved here as subpage (Inga)
• Antje: make page ready for review

Modification History

Excerpt
This article gives information on tagging and schema flow functionality (secondary object types) in the context of a document's lifecycle.

...

Secondary object types defined in the schema—marked as "floating"—are used to provide the additional properties and enable a "Schema Flow". They can easily be added or removed using the known endpoint for updating metadata (POST /api/dms/objects/{objectId}) to a document's instance. As a result, an extended set of properties can be made available and removed again later on if only needed temporarily. 

>> Changing Schema Structures ("Schema Flow")

Stateful Processing Using Tags

In document lifecycle management, multi-stage and asynchronous processes are not uncommon—quite the contrary. The first process steps are carried out with the highest priority. More complex and currently not absolutely essential process steps are carried out asynchronously with a lower priority. This saves time, and carrying out operations in parallel lets you distribute resources more evenly. To resume a process chain, additional information about the current status of the process is necessary. In order to not mix an object's metadata with its status data, there is the possibility to tag objects. 

>> Tagging

Audit Trail

The audit trail is the history protocol of an object, serving to document its entire lifecycle. There are many different actions that trigger the creation of a new entry in the respective object's audit trail. In the article linked below, an overview of the different history codes is provided that can occur in the audit trail.

...