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.

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 — 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

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.

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)
2. Click the Export CSV button
3. The CSV file will be downloaded to your device

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

If audit logs 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