Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.truagents.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Summary

The History view acts as the workspace audit trail. The current app suggests that it is more than a simple event list. It supports filtering, pagination, event metadata, source tracking, and drill-in detail views for certain versioned objects.

​
Who this is for

  • Owners and admins
  • Operators diagnosing unexpected changes
  • Internal teammates validating who changed what and when

​
Where to find it in the app

  • Settings → History
TruAgents history page showing audit filters for source, event type, and date range Even when the event list is empty, the page structure is useful: it shows that audit review starts with filters for source, event type, and time window before you inspect individual rows. That supports the right habit of narrowing scope first instead of scanning blindly.

​
What the current history view suggests

The current UI appears to support:
  • filtering by source and event type
  • viewing actor and metadata information
  • inspecting timestamps and affected entities
  • opening additional details for selected history events
  • drilling into related version data for some items, such as campaign versions

​
Why this matters

As the workspace becomes more automated, teams need a way to answer questions like:
  • what changed
  • who triggered it
  • whether the change came from a user or another system source
  • what version or object was affected

​
When to start here

Start with History when the question is:
  • “What changed recently?”
  • “Who triggered this?”
  • “Was this a user action or another system source?”
  • “What earlier version or object explains what I am seeing now?”
Do not start here when the team is just trying to complete a normal workflow. History is for inspection and diagnosis.

​
Practical review flow

  1. filter to the likely source or event type
  2. inspect the actor and timestamp
  3. check the affected object or version
  4. open deeper detail when the history row points to a related versioned item
  5. only then decide whether the issue belongs in settings, campaigns, communications, or teammate access
Simple version: narrow first, interpret second.

​
Common mistakes

  • treating the audit trail like a primary workspace for daily operations
  • looking only at the timestamp without checking source or actor
  • debugging permissions or campaign issues without checking whether a prior change explains them
  • assuming every surprising behavior is a bug before reviewing recent history

​
Success checklist

  • Admins know where to look when they need an audit trail.
  • The team understands that history is for inspection, not primary workflow execution.
  • Important changes can be traced back to an actor, source, or related object.