Audit
Introduction
Flowable creates a technical audit trail (history) by default. When it is required to have a business audit trail, the audit task is the easiest way to do this. For a step-by-step guide please follow the how-to.
Properties
General
Attribute | Type | Description | Category |
---|---|---|---|
Model Id | Text | Model Id identifies the element within the process model. | The model id, name and documentation properties can be found on any element. They are used respectively to uniquely identify the audit task, to give it a user-friendly name and to add a free-form description. |
Name | Text | The name of the element. This is the name displayed in the diagram. | |
Documentation | Multiline Text | The documentation attribute additionally adds a description to the component. | |
Payload | List | The content of the audit log. | The payload is optional and might contain additional information that is stored together with the audit instance. An arbitrary number of additional data can be added to the payload. |
Creator Id | Text | Creator id points to the creator who created audit log instance. If empty, default audit service creator is used. | Audit instances generated by the audit task are meant to be queries through the REST or Java API. Configuring the following identifiers will make filtering easier. Creator id: If left empty, the currently authenticated user is taken by default. An expression resolving to a user id can be set here, if the instance should be created in the context of someone else. That might make sense for example if executing asynchronously and wanting to make sure the correct user is entered. External id: this one is completely custom. |
External Id | Text | External id points to the external system entity. | |
Type | Text | The audit log type. | Audit instances generated by the audit task are meant to be queries through the REST or Java API. To allow for filtering, various types can be set. Type and Subtype are both custom properties. The subtype should give more details about the type, but it's fully customizable. |
Sub type | Text | The audit log sub type. | |
Scope Id | Text | Scope id points to the scope under which the audit task log is created. If all of scope attributes are empty, current scope is used. | Scoping is an important aspect of an audit instance. A scope points to the context it belongs to. This can be a process or case instance or anything else. Audit instances generated by the audit task are meant to be queried later on. Adding proper scope information makes querying easier. The Scope id, Subscope id, Scope type can be used to associate it with the current instance and task information. The Scope definition ID can be used to point to the corresponding process or case definition, or something completely custom. |
Sub scope Id | Text | Sub scope id points to the sub scope under which the audit task log is created. If all of scope attributes are empty, current sub scope is used. | |
Scope type | Text with suggestions:
| Scope type defines the type of the scope and sub scope instances. If all of scope attributes are empty, current scope type is used. | |
Scope definition id |