Audit logs

What an audit record shows

A record identifies the action, category, outcome, severity, actor or system source, target, and timestamp. Where available, detail includes a safe reason, before/after changes, recorded role and label, request or job context, and approved operational metadata.

Current coverage

Audit categories cover authentication, authorization, members, roles, community settings, security, email, notifications, task boards, automation, events, documents, announcements, registration, chat, and system work where those workflows emit records.

Filters, search, and detail

• Filter by category, outcome, action, actor, target type, and community-local date range.
• Search action and target identifiers, matching actors, and retained request, correlation, or job references.
• Results are newest first and paginated; open one record for its approved detail.

Sensitive-data exclusion

Audit metadata is allow-listed, size-limited, depth-limited, and removes keys associated with passwords, password hashes, tokens, cookies, authorization headers, API keys, private keys, SMTP passwords, CAPTCHA secrets, and encryption keys.

Storage and trust boundary

Audit records are stored in the application database. They support operational review and investigation, but PE Community does not claim external immutable, write-once, or tamper-proof logging. Operators who require that property must export or forward records into an independently controlled system.

Review practice

Use audit history to investigate unexpected access denials, role and member changes, registration decisions, publication and delivery operations, task and automation outcomes, security changes, and chat-device or encrypted-media governance. Correlate the record with product state rather than treating a single entry as complete forensic evidence.