Audit Logs

Audit logs provide a comprehensive record of all significant actions performed within TestPlanIt. This feature is essential for security compliance, troubleshooting, and maintaining accountability across your organization.

Overview

The audit log system automatically captures:

• Who performed an action (user identity, email, IP address)
• What was changed (entity type, entity ID, field-level changes)
• When the action occurred (timestamp)
• Where the action originated from (IP address, user agent)

Accessing Audit Logs

To access the system-wide audit log viewer:

1. Navigate to Admin in the top navigation bar
2. Click on Audit Logs in the admin sidebar

note

The system-wide viewer is available only to users with administrative privileges.

Viewing your own activity

You don't need administrator access to review your own audit history. Open your profile (user menu → View Profile) and expand the Audit Log section. This view is automatically scoped to your own actions, so the user filter is omitted; the search box and the action, entity-type, project, and date-range filters work just like the system-wide viewer, except that it opens on all time rather than the current week.

Administrators can review any user's activity the same way by opening that user's profile.

Viewing a project's activity

Project administrators don't need system-wide access to audit a single project. Open the project and choose Audit Logs from the project menu to see the audit trail scoped to that project.

This view is available to system administrators and to Project Administrators assigned to the project. It works like the system-wide viewer — the search box and the action, entity-type, user, and date-range filters all behave the same, though it opens on all time rather than the current week — but every entry belongs to the current project, so the Project column and Project filter are omitted. The menu entry appears for any Project Administrator, but it shows entries only for the projects they are assigned to.

Viewing an item's activity

You can review the change history of an individual test case, test run, or session without leaving its page. Open the item and click the Activity button in the header to open its Activity Log — a slide-out panel scoped to that one item.

This view is available to anyone who can open the item — no administrator access required. It lists every recorded change to the item and its contents, each with the user who made it, the timestamp, and the before/after values. For a test run, that includes test cases being added or removed — collapsed into a single "N test cases added" / "N test cases removed" entry that names the affected cases — along with results being recorded and status changes; for a session, the results and field values captured during execution. Filter by action type and date range, and open any entry for full details. Related changes made in a single save are grouped together.

Tracked Actions

Authentication Events

Action	Description
LOGIN	User successfully logged in
LOGOUT	User logged out
LOGIN_FAILED	Failed login attempt
SESSION_INVALIDATED	An active session was invalidated
PASSWORD_CHANGED	User changed their password
PASSWORD_RESET	Password was reset
MAGIC_LINK_REQUESTED	Magic link sign-in requested for a user
TWO_FACTOR_SETUP_REQUIRED	Administrator enforced 2FA setup for a user
TWO_FACTOR_ENABLED	User completed 2FA enrollment
TWO_FACTOR_VERIFIED	User passed a 2FA challenge (SSO flow)
TWO_FACTOR_CODES_REGENERATED	User regenerated their 2FA backup codes

Data Operations

Action	Description
CREATE	A new record was created
UPDATE	An existing record was modified
DELETE	A record was deleted (soft delete)
BULK_CREATE	Multiple records created at once
BULK_UPDATE	Multiple records updated at once
BULK_DELETE	Multiple records deleted at once

Permission & Access Control

Action	Description
PERMISSION_GRANT	User/group granted access to a project
PERMISSION_REVOKE	User/group access revoked from a project
ROLE_CHANGED	User's system-wide role was changed

API Token Management

Action	Description
API_KEY_CREATED	A new API token was created
API_KEY_DELETED	An API token was deleted
API_KEY_REVOKED	An API token was revoked by an administrator
API_KEY_REGENERATED	An API token was regenerated

Security Administration

Action	Description
PASSWORD_POLICY_CHANGED	Password policy or lockout settings were modified
FORCE_PASSWORD_CHANGE	User(s) required to change password on next login (individual or bulk)
PASSWORD_REVOKED	A user's password was removed by an administrator
ACCOUNT_LOCKED	Account locked after exceeding failed login threshold
ACCOUNT_UNLOCKED	Account unlocked after lockout duration expired

System Configuration

Action	Description
SYSTEM_CONFIG_CHANGED	Application configuration was modified (includes queue operator actions, integration sync, LLM cache operations)
SSO_CONFIG_CHANGED	SSO provider settings were updated

Share Links

Action	Description
SHARE_LINK_CREATED	A share link was generated
SHARE_LINK_ACCESSED	A share link was opened
SHARE_LINK_PASSWORD_VERIFY	A password-protected share link was unlocked (success) or rejected (failure, for brute-force detection)
SHARE_LINK_REVOKED	A share link was revoked

Imports & Data Quality

Action	Description
IMPORT_STARTED	A data import run (e.g., Testmo) was kicked off; pairs with the worker's BULK_CREATE event when the import completes
DUPLICATE_RESOLVED	A duplicate-case scan result was resolved (merged, linked, or dismissed)

Data Export

Action	Description
DATA_EXPORTED	Data was exported from the system

Tracked Entities

All administrator-managed configuration changes are tracked, alongside the core test, project, and user entities. The following entity types are recorded in the audit log:

• Test Management: Test Cases, Test Runs, Test Run Cases, Test Results, Sessions, Shared Steps
• Project Management: Projects, Milestones, Issues, Tags
• User Management: Users, Groups, Group Assignments, Roles, Role Permissions, Project Assignments, Permissions
• Security: API Tokens, SSO Providers, SAML Configuration, Email Domains
• Workspace Configuration: Workflows, Statuses, Configurations (Categories & Variants), Milestone Types, Project Status / Workflow / Milestone-Type Assignments
• Fields & Templates: Case Fields, Result Fields, Field Options, Templates, Export Templates
• System Configuration: App Config
• AI & Integrations: Integrations, Project Integrations, Prompt Configurations, LLM Integrations, LLM Provider & Feature Configurations, Ollama Model Registry, Code Repositories
• Content: Comments, Attachments

Filtering Audit Logs

The audit log viewer supports filtering by:

• Date Range: View logs from a specific time period
• Action Type: Filter by specific actions (CREATE, UPDATE, DELETE, etc.)
• Entity Type: Filter by the type of entity affected
• User: Search for actions by a specific user
• Project: View logs for a specific project

Default time range

The system-wide viewer opens on the current week (Monday through Sunday). The audit log is the largest table in a mature workspace, and reading it end to end is a slow, expensive query that most visits don't need — so the view starts narrow and you widen it when you want history.

Open the date-range picker to change it:

• Pick a preset — Today, Last 7 days, This month, Last quarter, and so on.
• Drag out any custom range on the two-month calendar.
• Choose All time to drop the date bound entirely and read the full history.

The selected range governs everything the page derives from it: the rows listed, the "showing X of Y" count, and the CSV export.

The already-scoped views — your profile's Audit Log, a project's Audit Logs, and an item's Activity Log — open on all time, because each is bounded to a single user, project, or item.

Audit Log Details

Each audit log entry contains:

Field	Description
Timestamp	When the action occurred
User	Who performed the action (name, email)
Action	The type of action performed
Entity Type	The type of record affected
Entity ID	The unique identifier of the affected record
Entity Name	A human-readable name for the entity
Project	The project context (if applicable)
IP Address	The client's IP address
Changes	Field-level changes (for UPDATE actions)

Viewing Changes

For UPDATE actions, you can view the specific fields that were modified:

• Old Value: The previous value before the change
• New Value: The new value after the change

Sensitive fields (passwords, tokens, API keys) are automatically masked in the audit log.

System-initiated events

Some audit events are initiated by the system rather than a user — for example, scheduled jobs (budget alert checks, forecast recalculations, milestone-due notifications) or worker-to-worker chained operations that don't have an originating user request. These events are recorded with:

• User ID: the literal string __system__
• User Name / Email: empty
• Metadata: a systemReason field naming the scheduled job or worker that triggered the event (e.g., scheduled:budget-alert-check, scheduled:forecast-recalc, scheduled:milestone-due-notifications)

In the audit log viewer these rows display System in the User column. In CSV exports, the User ID column contains the literal __system__ value, which makes it straightforward to include or exclude system events in spreadsheets and reporting tools.

tip

To find only user-initiated events, filter the audit log viewer by a specific user — system-initiated rows will be excluded automatically.

Group role mapping changes

Changes driven by group role mapping are fully audited:

• Setting a group's Mapped Access Tier or changing the fallback default is recorded as an UPDATE on the group (or app configuration), attributed to the admin who made the change, with the field-level before/after.
• Each resulting per-user access-tier change is recorded as a separate UPDATE on the user. These recompute events are attributed to the SCIM access-recompute worker and carry source: scim (with the originating group and token IDs) in their metadata, so they can be told apart from manual access changes.

Role mapping and per-project mapping changes

The other two mapping surfaces are audited the same way, each with the field-level before/after and the acting admin:

• Creating, retiering, or removing a role mapping is recorded against ScimRoleMapping, keyed by the role value. Removing a mapping is recorded as a DELETE; the per-user recompute it triggers is scoped to the holders of that role.
• Granting, changing, or withdrawing per-project access for a group is recorded against GroupProjectAccessMapping, keyed by group and project.

One situation worth watching for, recorded against the affected GroupProjectPermission:

• scimProjectMappingSupersededManual — a per-project mapping took over a permission row an admin had previously assigned to that group by hand.

SCIM token and cross-IdP events

• Token rotation is recorded as an UPDATE on the ScimToken carrying scimTokenRotated, the overlap window applied, and when the superseded bearer stops working.
• Cross-IdP conflicts — a write refused because the user or group belongs to a different identity provider — are recorded against the target row with scimTokenConflict, naming both the owning and the requesting IdP. These also surface in the conflict log on /admin/scim.

Exporting Audit Logs

Administrators can export audit logs to CSV for compliance reporting or external analysis:

1. Apply your desired filters (search, action type, entity type, date range)
2. Click the Export CSV button
3. The CSV file will be downloaded to your device

warning

The export covers exactly what the filters currently select, date range included. Since the viewer opens on the current week, widen the range — or choose All time — before exporting a compliance archive, or the CSV will contain only this week's entries.

The exported CSV includes all filtered audit log entries with the following columns:

• Timestamp
• Action
• Entity Type
• Entity ID
• Entity Name
• User
• Email
• Project
• IP Address
• User Agent
• Metadata (JSON)

info

Audit log exports are themselves logged as DATA_EXPORTED events for accountability.

Technical Details

Asynchronous Processing

Audit events are processed asynchronously using a background queue to ensure that audit logging does not impact application performance. Events are queued immediately and processed by a dedicated worker.

Multi-Tenant Support

In multi-tenant deployments, audit logs are isolated by tenant. Each tenant can only view audit logs for their own data.

Best Practices

1. Regular Review: Periodically review audit logs for unusual activity
2. Export for Compliance: Export logs regularly for compliance documentation
3. Monitor Failed Logins: Watch for patterns of failed login attempts
4. Track Permission Changes: Pay attention to permission grant/revoke events
5. Investigate Bulk Operations: Review bulk operations for unintended changes

Troubleshooting

Audit Logs Not Appearing

First check the date range — the system-wide viewer opens on the current week, so anything older is filtered out rather than missing. Choose All time in the date-range picker to confirm.

If entries genuinely are not being recorded:

1. Verify that the background worker is running (pnpm workers)
2. Check that Valkey/Redis is connected and healthy
3. Review worker logs for any errors

Missing User Information

If audit logs show missing user information:

1. The action may have been performed by a system process — look for __system__ as the User ID and a systemReason field in the metadata, which identifies the scheduled job or worker that triggered the event (see System-initiated events)
2. The user session may have expired before the audit was captured
3. Check that the user is properly authenticated