Audit
How Control's Flow, Schedule, and API activity feeds the platform audit trail.
Control can produce entries in the platform-wide audit trail — a structured, cross-system record of business-relevant changes, exposed through a dedicated UI built for business users such as HR, support, and auditors, rather than IT administrators. The event / change package / change model, the audit UI, and its REST API are documented once, generically, in Audit. This page covers what is specific to Control.
Where Control's events come from
Section titled “Where Control's events come from”| Control feature | Audit source type |
|---|---|
| A Flow run | Flow |
| A Schedule job execution | Schedule |
| An API endpoint call | API |
| Anything recorded outside those three | Manual |
Configuring Audit in Control
Section titled “Configuring Audit in Control”A new installation of Control 1.4.0 or later comes with Audit configured: a JdbcClient module for the audit database (jdbc.json), the Audit module (audit.json), and the Control module with an Audit tab (shell.json). Access is limited to users with the auditor role.
If you upgrade from Control 1.3.0 or earlier, these files are not added. See Enable Audit after an upgrade.
The Audit module shares the /control context and login session with Forms, and is served at /control/audit. See Audit for every configuration property. A typical Control deployment also configures LDAP enrichment for the object types Control's flows and pipes most often write to — users and groups:
{ "name": "Audit", "config": { "http_listener": "default", "http_context": "/control", "context_path": "/audit", "jdbc": { "schema": "AUDIT" }, "enrichment": { "ldap": { "object_types": { "user": { "display_name_attributes": ["displayName", "cn"] }, "group": { "display_name_attributes": ["displayName", "cn"], "reference_attributes": { "member": { "value_object_type": "user", "identity_bearing": true } } } } } }, "requires_any_role": ["auditor"] }}In this section