Introduction and Key Concepts

The role of the history service is to store an log (a history) of actions that occur while users interact with services on your site, primarily through forms and workflow processes.

Anything capable of communicating with the API Server can potentially access the History Worker and read or record history data.

Each history is written with a unique ID generated by the worker, and a key made up of five labels. Labels follow a set of conventions described in the documentation below and provide a convenient way to retrieve histories of a certain type.

Once a history entry has been created, whatever created it will then (generally) write events to it. These events can store any data the you would like, provided it is written in a valid JSON format. Events are automatically timestamped and added sequentially to the history.

Events can be set as public or private, allowing products like the Self Service and User Requests templates to only display certain events to certain groups of users.

Finally a history can be "sealed" preventing further events from being written to it. Histories belonging to workflow process instances are automatically sealed when the process ends. They can also be sealed using a form action or direct request to the History Worker.