Read audit trails
Find the history for each resource, inspect actors and changes, and distinguish audit records from notifications and AI progress.
Use an audit trail when you need to establish who changed something, when it happened, and which work it affected. Sorena AI shows these records in the relevant resource's Activity or History view. The available detail depends on the event, your access, and the workspace's licenses.
Start with Activity for a grouped overview. Open the resource's own history when you need individual events, review decisions, or changes that the overview does not include.
Find history by resource
| Resource or question | Where to look | Examples of recorded changes |
|---|---|---|
| Workspace settings and access | Workspace > Activity | Workspace details, invitations and membership, authentication and SSO settings, AI-service configuration, business units, and license or credit notices. |
| Project | Projects Hub, open a project, then Activity | Project details, direct and team access, workspace sharing, related artifact changes, assessment-item changes, and file operations. |
| Assessment | Open the assessment's Activity, then full activity when needed | Artifact settings and status, seed files, imports and exports, autopilot runs, generated answers, and confidence updates. |
| Assessment question | Select the question and open its Activity | Answer and compliance changes, review status, assigned reviewers, comments, and question creation, import, or ordering changes. |
| Contract | Open the contract's Activity; select a section for section history | Clauses, parties, seed sources, reviewers, comments, approval and workflow changes, and autopilot outcomes. |
| Organizational document | Open the document's Activity; select a section for its history | Content, applicability, review and approval, publication, references, control mappings, stakeholders, and template updates. |
| Timeline artifact | Open the timeline artifact's activity | Milestones and events created, changed, or deleted; category and timeline-setting changes. The timeline's dated business events are separate from its change history. |
| Project files and folders | The owning project's Activity, filtered to files | Uploads, generated files, folders, renames and moves, deletions, and processing retries or cancellations. |
| Management system | Management systems, open a system, then History | Requirement and section changes, assessment requests and outcomes, evidence links, owner assignments, document imports, template population, and applicability exports. |
| Management-system requirement | Open the requirement's Activity | Human review, evidence added or removed, linked-template changes, assessment and gap-fix outcomes, and reviews superseded by changed evidence. |
| Risk | Open the risk's Activity | Scores, severity, status, acceptance and review decisions, owners, reviewers, treatment actions, evidence, controls, comments, relationships, and threat information. |
| Research chat | Open its timeline and Session events | Renames, sharing and role changes, message edits or deletions, queue changes, steering, tool-permission changes, and turn-control requests. Use run history for the work performed within a turn. |
| Team | Teams, open a team, then Team Activity | Team details, members and their roles, and workspace-sharing changes. |
| Your account | Profile, open your activity | Profile and sign-in-related account history. Workspace admins and owners can inspect another current workspace member's account history through member controls. |
| Support request | Help, open a request, then its Activity | Request and reply edits, status changes, attachments, and access or sharing changes. Access to the request is required. |
| GitHub connection and assurance | Workspace > Integrations, open the GitHub connection; also check workspace activity | Installation and permission changes, sync health, and available deployment, rule, security, and organization-audit records. See GitHub assurance. |
The table describes supported types of activity. A history only contains records available for that resource; it does not promise that every field edit has a separate entry or that every operation appears in every view. Some export records appear in an artifact's history but are omitted from grouped Activity. Risk history and chat, support, account, and team history also have separate destinations.
Inspect a recorded change
- Check the workspace and resource named in the page or dialog.
- Find the event. Use its history filters, pagination, or Load more controls where offered.
- Open the row or View event details to inspect the available details.
- Read the actor, timestamp, affected resource, and recorded changes. Before-and-after values, status transitions, reasons, or counts appear when the event recorded them.
- Follow Open, View resource, or a related-history link when offered to inspect the current resource.
The shared Activity details dialog groups additional fields under Changes and context. Some resource histories show the same information directly in a row. A record with little detail does not imply that nothing changed; some event types record an action and time without a field-by-field comparison.
An AI attribution label identifies an AI-assisted action when that information was recorded. An automated actor identifies work performed automatically. Review the resulting content and its approval state when judging whether the work is correct. A former or deactivated member can remain named in historical records; their current access is a separate question.
The event's importance or severity describes the change being reported. For a risk's current severity, treatment, or acceptance decision, open the risk record.
Audit history, notifications, and work status
| View or action | What it tells you |
|---|---|
| Resource activity or history | The available record of changes to that resource. |
| Grouped Activity | Related changes combined into updates, with a sample and links to individual history. |
| Notifications | Updates delivered to you, with your own read state and delivery preferences. |
| Dashboard work items | Work that needs attention, such as a review, assignment, deadline, or workspace task. |
| AI progress and run history | What happened during a run, including steps, results, interruptions, and failures. A started or queued action still needs its outcome checked. |
| Billing and usage | Credit, spend, consumption, and productivity measures for a reporting period. |
Marking a notification read does not approve an answer, complete a review, or resolve a risk. Changing notification delivery preferences controls delivery; it does not remove the resource's saved activity.
Where Dismiss is offered, dismissal changes the event's active-history state. The record can still be found in a view that includes dismissed entries. Restoration is available only in the histories that offer it. Dismissal alone does not reverse the recorded change or establish that the underlying issue is resolved. Follow the confirmation shown: some artifact workflows can combine event dismissal with a separate review or exclusion decision.
Choose filters that answer the question
Use the affected resource and time window first, then narrow to an event type or person. In project and workspace history, All activity includes active and dismissed records; Active and Dismissed select one state. Grouped Activity has separate active and dismissed histories. Research chat history uses What happened and date controls, with Who when people are available to select.
Date filters use UTC. People offered in filters often come from already loaded history, so an absent person is not proof that they never acted. Clear filters or load more history before narrowing again. The available controls vary: a risk's dedicated history uses pages, while document and contract histories use their own activity controls.
To investigate a changed answer, start with the question's history and compare its review and answer events. To investigate a sharing change, start with the project, chat, team, or workspace whose access changed. To investigate an AI run, compare its request, progress, and final outcome, then inspect the artifact or risk it changed.
Access and missing records
History follows resource access. Reading a project history requires access to that project; chat history requires access to that chat and the Copilot license. Management-system history depends on the IMS license. Seeing a workspace event does not give you access to private project content or restricted integration details. See Roles, access, and licenses.
For personal account history, ordinary members can read their own records. Workspace admins and owners can read account history for other members of that workspace. Support history is limited to requests you can access. GitHub-sensitive details depend on integration-management access and can be hidden from other readers.
Personal account history includes account-level actions such as sign-ins and profile updates. To find a person's changes to project work, use that project's history and its person filter instead.
If an event or link is missing, check the workspace, resource access, date window, dismissal state, and whether you are reading a summary or scoped history. Deleted resources can have names or links withheld. Some records retain historical attribution after a member leaves; that attribution does not grant the former member access.
Use Refresh or the view's retry action if loading fails. Previously loaded records can remain visible after a failed refresh, so read any warning before relying on the latest displayed time. When asking support to investigate, include the resource name, approximate time and time zone, and the steps you followed. Share sensitive record details only through a support request you intend the Sorena team to see.