Investigate activity with the audit log

Before you begin

Know what question you are actually answering. "Who changed this pay application" is a record-scoped question. "What did this user do in March" is a user-scoped question. "Did anything unexpected touch our financial records" is a pattern question, and each one is a different starting point in the log. Audit log access is admin-restricted, since the log itself reveals activity across the whole company.

Steps

1. Go to Admin → Audit Log. The default view is chronological across all activity, which is useful for browsing and poor for investigating.
2. Filter by what you know. Scope to a specific record to see its complete history, to a user to see their session activity, to a date range, or to an action type such as permission changes or deletions.
3. Read an entry in full. Each records the actor, the timestamp, the action, the affected record, and the before and after values on changed fields. A change entry that shows the prior value is what makes the log usable rather than merely present.
4. For permission questions, filter to role and permission changes. Every role assignment, removal, and per-project grant is logged with who made it, so a question about why someone could see a financial report six months ago has an answer.
5. For document questions, cross-reference the audit log against the document register. The register shows document state transitions, and the audit log shows the user actions behind them.
6. For integration questions, filter to connector activity. Inbound and outbound sync events are logged with their payload identifiers, which is how you tell an accounting posting that failed from one that never fired.
7. Export the filtered result when you need to hand it over. The export carries the same fields as the on-screen view so nothing is lost in translation.

What happens next

The audit log is append-only. Entries cannot be edited or deleted from the interface, including by admins, which is what makes it evidence rather than a convenience feature. Financial records go further: the job cost ledger is hash-chained, so tampering with a historical entry breaks the chain visibly rather than passing unnoticed.

Where the record lives

Audit entries are retained under Admin → Audit Log according to your retention policy, and audit data is normally given a longer retention period than the records it describes. A legal hold applied to a matter extends to the related audit entries, so disposition does not quietly remove the trail while the underlying records are preserved.

Troubleshooting

A change happened but no audit entry exists: check whether the change came through an integration rather than a user session. Connector-originated changes are logged under the connector's service identity rather than under a person.

Too many entries to read: narrow by action type before narrowing by date. Most investigations care about a handful of action types, and filtering on those first cuts the volume by an order of magnitude.

Before and after values are blank on an entry: the action created or deleted the record rather than modifying it. A creation has no prior state, and a deletion has no subsequent one.

Need activity from before the current retention window: check your backups. The audit log honors the retention policy you configured, and shortening that window is a decision worth revisiting if you are hitting this regularly.