The audit log

Audit log contents

Not all changes trigger an audit log entry. The types of entity for which changes are logged are:

Users
Teams
Named areas
Accounts
Account Secrets
Contacts
Avatars
Addresses
Canned responses
API keys
Domains
Webhook registrations
Webhook registration events
Dialog bots
External messengers

Configuration properties

If the configuration property is of the type SECRET or MULTILINE_SECRET, the audit log displays the masked value and a hash of the actual value.

Text properties
Metadata properties
Conversations
Conversation templates
Blobs

Creating, updating, or deleting an entity results in an audit log entry.

Audit log entries contain metadata related to the entity that was modified and to the changes made to the entity. The metadata collected in the audit log entry consists of:

The date and time the change was made
Details of the entity in question:
- Its name, if it has one. This will not be the case for most entities.
- The entity’s ID
- The type of entity
Details of the user who made the change:
- Their username
- Their user’s ID
- The user’s role
The interaction type, consisting of:
- How the interaction took place:
  - The UI
  - The Unblu web API
  - A job run periodically by Unblu
  - An action triggered by a user interacting with Unblu in some way
  - Some other type of interaction, referred to as Internal
- The name of the method called
Information on how the user was authenticated. The type of authentication will be one of the following:
- Authenticated, if the user was authenticated by Unblu
- Anonymous, if no authentication took place
- Propagated (virtual), if authentication was handled by another system
The IP address that the change was made from
Information on whether the user who made the change was impersonated
The type of change that is logged:
- Created
- Updated
- Deleted
The state of the affected entity before and after the change:
- If a new entity was created, the audit log entry will only have a new state
- If the entity was updated, the audit log entry will have both a new and an old state
- If the entity was deleted, the audit log entry will only have an old state. If the entity in question was an account, the old state will be empty.
Details about the owner of the affected entity, if it has one:
- The type of the owner entity
- The ID of the owner entity

Accessing the audit log

The audit log is accessible from the standard Unblu UIs (Account Configuration interface and Global Server Configuration interface) and via the Unblu web API.

The Account Configuration interface guide describes the various options you have for searching the audit log in the UI.

Consult the Unblu web API reference for details on how to search the audit log using the Unblu web API.

Permission to access the audit log

Because the audit log contains personally identifiable information (PII), access to it is restricted.

Administrators may access the logs of entities that are part of the account they administer.
Technical administrators don’t have access to the audit logs.
Superadministrators can only access audit log entries related to the following entities:
- Entities with the owner type "Global", such as configuration properties in the GLOBAL scope
- Account entities, such as the account details or configuration properties in the ACCOUNT scope
- Entities in their own account, as if they were administrators of the same account
Superadministrators have no access to the audit log of entities for accounts that they impersonate into.

Data retention

By default, audit log entries are kept for 365 days before being deleted. Unblu deletes audit log entries that have reached the maximum retention period once a day.

When you delete an account, all of the audit log entries related to that account and its related entities are deleted. A single audit log entry remains showing that the account was deleted. This log entry does not show the old state of the account to ensure that no personally identifiable information (PII) remains in the audit log.

The settings outlined here are all configurable; see the following section for further details.

Configuring the audit log

It isn’t possible to turn off the audit log.

There are a number of properties available to configure the audit log.

You can specify how Unblu should behave if an error occurs while attempting to write the audit log:

com.unblu.storage.database.audit.persistRetries specifies the number of retries to make if writing an audit log entry fails.
com.unblu.storage.database.audit.persistRetriesDelay is the delay, in seconds, between attempts to write an audit log entry.

Other configuration properties determine how long audit logs are retained:

com.unblu.storage.database.audit.auditLogRetentionCheckInterval specifies the frequency, in seconds, with which Unblu checks whether the retention period of audit log entries has been reached.
com.unblu.storage.database.audit.automaticAuditLogDeletion: By default, Unblu deletes audit log entries when one of two conditions are met:
- The maximum retention period for a log entry has been reached.
- The account that the audit log entry is related to is deleted.
If you set this configuration property to false, audit logs are not be deleted automatically.
- Audit logs are retained beyond their maximum retention period.
- Audit logs are retained if the account they pertain to is deleted.
Use com.unblu.storage.database.audit.auditLogRetentionMaxNumberOfDeleted to specify the maximum number of audit logs to delete in each job run. The default value is 1000.

One configuration property affects the audit log in the UI:

com.unblu.configuration.client.core.audit.AuditChangeHistoryListComponent.limit specifies the number of log entries displayed in the UI.

Audit log data is stored in the table audit_table.