# Configuration Audit Log

In environments where multiple users work on the same configuration, users might find some details updated or missing without prior notification. To address this, our platform incorporates an audit trail log to trace all configurations.

On our platform, when users add/update/remove configured data (e.g. product, rating, rule, indeed, and public settings) in the backend system, the changes they make will be automatically recorded. In the event of data discrepancies, users can navigate to **Public Setting** > **Audit Log** to view the change details of the relevant data.

## User Scenario

For anybody who wants to trace who changed which configuration, when, and how, e.g. to investigate unexpected configuration changes or to review operations before/after a deployment.

## What Is Recorded

Each record captures:

* **Who**: the user who made the change.
* **When**: the time of the change.
* **What**: the changed object (business category, entity, and its identifier), and the change type — **Create**, **Update**, or **Delete**.
* **How**: the change detail — for updates, a field-by-field before/after comparison; for creations, the initial values; for deletions, the removed values.

Basically, there can be two scenarios causing the change:

1. Change via configuration UI <br>
If the user identified in the record is an actual username, the record is changed via UI or API.

2. Change via configuration data deployment<br>
If the user identified in the record labeled as **Virtual**, the data is changed via configuration deployment. Batch imports (e.g. Excel upload) are also flagged as batch operations.

## Search

Users can search the change records with the basic filters:

* **Change time range** — mandatory, defaulting to the last 30 days.
* **Entity Category** — a business-friendly classification of the changed object, such as Code Table, Rating, Rule, Product, Data Dictionary, Currency, Workday, Numbering Template, Message, and more.
* **User**.
* **Audit Type** — **Database** for changes made via UI or API, **DataIO** for changes made via data deployment or import.

Advanced filters are available for more precise locating:

* TraceId, EntityId, ReferenceId (parent object).
* Table name and entity name.
* Catalog (the data function of the DataIO import).
* Change type (Create / Update / Delete), source service, whether it is a batch operation.
* Business code and a content keyword that fuzzy-matches the change detail.

Click **View** of the record, and users can check the details of the record.

![Configuration Audit Log 2](./image/public_setting/config_audit_log_search2.png)
![Configuration Audit Log 3](./image/public_setting/config_audit_log_search3.png)


## Log Detail

The detail dialog shows:

* **Basic info**: user, trace id, entity id, entity category, entity name, table name, audit time, change type.
* **Other info**: source service, catalog, business code, request IP, API path, headline, and description of the operation.
* **Change detail**: the before/after values are displayed side by side, so users can directly see which fields were changed and how.

For records generated by DataIO imports, users can also download the **import report** and the original **uploaded file** for further investigation.

## Entry from Configuration Screens

Besides the dedicated search page, accessing the detailed configuration screens facilitates a direct transition to the configuration audit UI, where users can view the change history.

For example, exchange rate, numbering template, message, language, configuration group, code snippet, and DSL script screens provide a **ChangeHistory** entry per record, which opens the audit records of that specific record only.

![Rule Audit](./image/public_setting/rule_audit.png)

## Coverage

The audit trail covers configuration-related data across the platform, including product, rating, rule, validation rule, code table, data table, rate table, data dictionary, i18n, script, currency, exchange rate, workday, numbering template, message, menu, search index, upload, batch definition, preference, event bridge, and user/role/permission management.

## Notes

Finally, please pay attention that:

 - This feature is only available to track the change history for configuration-related data. Data like sales channels or customer information, which are considered instance data, will not be captured here.

 - This feature is only for platform internal usage. If the tenant team wants to capture audit information, it is necessary to call the container audit service to capture and retrieve it.

 - It is recommended to keep the query time range within about 3 months for a better search performance.

 - When filtering by a specific user, batch operation flag, or content keyword, DataIO records (changes made via deployment) are not included in the result — remove those filters if deployment changes need to be checked.