How to Use the Audit Trail for Configuration Change Tracking

Overview

Mango by Radix IoT’s audit trail records configuration changes: who created, modified, enabled or disabled, or deleted a data source, data point, user, role, event handler, event detector, template, publisher, mailing list, or other configuration object.

It does not track logins, setpoint commands, or event acknowledgments. Login activity belongs to the regular Events system. Setpoint commands never reach the audit trail either, but the value Mango stores does record who set it — see Where to Look Instead.

Prerequisites

• A running Mango 4.x or 5.x instance
• Superadmin permission
• A defined retention requirement for configuration history

What the Audit Trail Captures

Enabling and disabling an object is recorded as Modify, with the changed enabled flag in the event context. There is no separate toggle action type. Optional modules contribute their own audit types when installed — Advanced Scheduler audits schedules and calendar rule sets, and Excel Reports audits report templates and generated reports.

Taking those one at a time:

• Logins, logouts, and failed login attempts raise System Events. View them on Events.
• Setpoint commands are not audit entries. They are not invisible, though: a value you set from the interface or the API is stored with a source annotation naming you, by default Set by user: <username>, which you can see in the point’s value history.
• Event acknowledgments are part of the event lifecycle and are recorded on the event itself.
• Dashboard changes and JSON configuration import/export are not recorded.

Viewing the Audit Trail

From Administration > Admin home, find the Server status card and click More details, then select the Audit trail tab. Neither System status nor Audit trail appears in the navigation menu — both are hidden and superadmin-only — so there is no menu item to hunt for. The route is /system-status/audit-trail, and the page requires superadmin permission.

Available filters include:

• Alarm level: All, or one of Minor, Information, Important, Warning, Urgent, Critical, Safety. (The stored values are NONE and LIFE_SAFETY, but the labels shown are Minor and Safety.)
• Change type: Create, Modify, or Delete
• Type: The kind of object that changed
• User: Actions performed by a specific user
• Date filter: Restricts results to the dashboard’s active time range

Each entry shows alarm level, change type, object type, message, timestamp, and username. Click a row to see the change context — for a Modify entry that lists each changed property with its old and new value.

Common Use Cases

Investigate a Configuration Change

If a changed polling interval causes communication problems:

1. Filter Type to Data Source.
2. Narrow the time range to when the problem began.
3. Find the relevant Modify entry.
4. Review the message, username, and timestamp.

Produce Configuration Compliance Records

Use the audit trail or REST API to report:

• Changes to regulated data sources and points
• User-account and role changes
• System-setting changes

Keep the scope explicit: this is configuration history, not login or setpoint history.

Where to Look Instead

• Successful and failed logins: Open Events and filter for the relevant System Event type.
• Event acknowledgments: Review the event itself, including who acknowledged it and when.
• Setpoint commands: not in the audit trail, and there is no setpoint log you can query. But Mango does attribute them: a value written through the point-value service is stored with a source annotation, by default Set by user: <username>, visible in the point’s value history. If you need setpoint history you can search or report on, build it deliberately — the annotation gives you attribution, not a queryable audit.

Audit Trail Retention

Audit events are stored in a dedicated database table and have purge settings separate from other events.

• Configure the audit-event purge period in System settings. The default is 1 year (auditEventPurgePeriodType = years, auditEventPurgePeriods = 1).
• Match retention to regulatory requirements.
• Account for database growth when retaining years of history.
• Review the oldest available audit event periodically to confirm the purge policy is working as intended.

Integrating Audit Data with External Systems

For reporting or SIEM integration:

• Query GET /rest/latest/audit with an admin-authorized account. The endpoint supports RQL queries.
• GET /rest/latest/audit/list-event-types returns the audit event types registered on your instance, which is the reliable way to see what your modules add.
• In a global script with the script.bindings.services permission, use services.auditEventService.list() or services.auditEventService.query(rql).
• Use a process event handler to forward selected System Events, such as failed logins. This forwards regular events, not audit-trail records.

The audit service returns audit records with fields including type name, change type, user ID, object ID, timestamp, and message.

Best Practices

• Give each person a unique user account; shared accounts prevent reliable attribution.
• Review configuration changes on a regular schedule.
• Set retention based on compliance needs and available storage.
• Keep the audit trail enabled.
• Pair the audit trail with Events for login activity.
• Build a separate process if setpoint history is required.

Verification

• Create or modify a test configuration object.
• Open the audit trail the way described above: Administration > Admin home, Server status card, More details, Audit trail tab. (Or go straight to /system-status/audit-trail.)
• Confirm the entry shows the correct Change type, Type, user, timestamp, and message.
• Enable or disable the object and confirm the result is recorded as Modify.
• Verify login events appear under Events, not in the audit trail.

Troubleshooting

A Configuration Change Is Missing

• Confirm the object type supports configuration auditing.
• Widen the active date range.
• Clear restrictive User, Type, or Change type filters.
• Verify you are looking for Create, Modify, or Delete—not an operational action.

Login Activity Is Missing

Open Events. Successful and failed logins are System Events and are not audit-trail entries.

A Setpoint Change Is Missing

This is expected — setpoints are not audit events. Check the point’s value history instead: the stored value carries a source annotation naming whoever set it.

Script Cannot Query Audit Records

• Confirm the script has script.bindings.services permission.
• Use services.auditEventService, not direct JDBC.
• For an external client, use GET /rest/latest/audit with appropriate authorization.

Related Guides

• Understanding Role-Based Access Control in Mango
• How to Create and Configure User Accounts
• How to Use Mango Logs for Troubleshooting
• How to Configure System Permissions by Role
• Understanding the Mango Event Lifecycle