# Investigate activity with audit reports

Audit Reports provides several kinds of evidence. Open it from Common, then choose the report that answers your question. Audit Log shows recorded data changes. Client Log Report helps trace client lifecycle events. Session reports concern access, while view logs concern recorded viewing activity. These are different questions, so do not treat a login as proof that a particular field was edited. Start with a specific client, time period, and event you want to understand.

For a data change, open Audit Log and narrow the dates, table, and key ID. In this example, the table is Client and the key identifies Casey Training. Read the timestamp, user, field, old value, and new value across the row. The service-assignment entry changes from blank to Demo User one hundred sixty two. That is evidence of the recorded assignment change. It does not explain the business reason by itself, so read the related task or note for context.

Next, compare the audit entry with the current client record. Casey's Admin screen now shows the same service owner. If you are investigating portal access, use the corresponding portal session reports rather than assuming the staff login report covers the client. If the question concerns communication preferences, compare the recorded preference change with the relevant note and workflow. Keep each conclusion limited to what that source records, and investigate gaps instead of filling them with assumptions.

Document a finding with the record ID, time range, observed change, and supporting references. Separate what is confirmed from what still needs investigation. Route an unexplained access or data-change issue through your organization's process, and preserve the relevant evidence. Corrections belong in the normal authorized workflow, not in an attempt to rewrite the audit trail. After a correction, verify the saved record and the new history so the complete sequence remains understandable.