Activity Log
The Activity section on a record shows what has happened to it — every business event the record raised, and events on other records that concern it, newest first. It answers "who changed this, and when" without anyone having to remember.
Activity is recorded automatically. There is nothing to switch on, and no way to edit or delete an entry: the log is append-only.
Where it appears
Every record whose changes raise domain events carries an Activity section in its rail:
| Module | Records |
|---|---|
| Organizations | Teams, Teams of Teams |
| Planning | Planning Intervals, PI Objectives, Risks |
| Work Management | Sprints |
| Project Portfolios | Portfolios, Programs, Projects, Strategic Initiatives |
| Strategic Management | Strategic Themes |
| Product Management | Products, Versions, Releases, Release Packages, Deployments |
| Administration | Users (including their personal access tokens), Identity Providers, Connections, Holiday Calendars, Scoring Models, Status Workflows, Work Processes, and the Scheduling and Sprint Metrics system settings |
Seeing a record's activity needs only the same View permission that lets you open the record.
Records not listed here have no Activity section, because nothing they do raises an event yet.
Reading the log
The section is a master-detail view: the timeline of events on the left, the selected event's full detail on the right.
Each timeline entry shows a tag for the kind of change (Created, Updated, Schedule Change, Status Change, State Change, Health, Removed, or Baseline), a short summary, who made it, and when. Hovering the timestamp shows the exact time to the second.
Who made the change is one of:
- A person — the employee behind the change, with their avatar. Their name links to their employee page, and their avatar opens their profile card. An account with no employee record shows as User.
- Automation — Wayd reacting to something a person did, shown as started by that person. They chose the action that set it off, not the change it made, so it is never shown as their own edit.
- Data Import or Integration Sync — a CSV import, or an integration syncing from an external system.
- System Process — no human actor: a scheduled job, a message being delivered, or startup work.
A change made by an application you connected by signing in, such as an AI agent, is still yours, and the entry adds via the site the application belongs to, the same site the connection request named. Hovering it, or opening the entry, shows the application's full address. A change made with a personal access token names no application, because Wayd cannot tell which tool used the token.
Selecting an entry opens its detail, which adds the event type, the module it came from, the kind of record it targeted, and the payload — the full data the event carried, as recorded at the time.
A change records what it replaced as well as the result: a timeline change carries the previous dates, a lifecycle change the lifecycle it moved from, a details edit the name and description it overwrote, and a role or theme change who and what was added and removed. One entry is enough to see what an edit altered. Entries recorded by earlier releases may carry only the result.
Some changes concern more than the record they were made on. Moving a product under a new parent changes the product, but both its old and new parent lost or gained a child, so the move appears in all three Activity sections. On a record other than the one changed, the entry says which record it was made on, and its detail links to it. Where that record has since been removed, the entry stays and names only its kind. Today this applies to products moving between parents, to product dependencies, which also appear on the product depended on, and to a team's membership in a team of teams, which also appears on the team of teams. A team of teams names the team a membership entry was made on but does not link to it yet.
Two entries can be compared: Compare changes on an event shows its payload beside the previous one for the same record, with changed fields called out. It is most useful across different kinds of change, or for older entries that recorded only the result.
Use the search box to narrow the timeline by event, actor, type, or the site of the application a change was made through. Long histories load a page at a time — Load more activities fetches the next page.
Exporting
Export in the section header writes the history to a JSON file. Choose what to include:
- All events — the complete recorded history.
- Date range — events within a timeframe, with presets for the last 7, 30 or 90 days and this year.
- Current search results — only what your search matched. Offered when a search is active.
The export walks the full history rather than only what is on screen, so a filtered export still covers every matching event.
What is recorded
An entry holds what happened, on what record, by whom, and when — plus the event's payload and a correlation id tying together every change made by the same request or job. Events also carry a schema version, so a payload recorded by an older release still reads correctly.
The log records business events — a project's details being updated, a version being cut, a workflow being published. It is not a field-level audit of every column.
A project's status changes appear here and in its own status history section. The two agree: both are written from the same transition, so neither can show a move the other does not. Status history shows transitions alone, in lifecycle order; the Activity section shows them alongside everything else that happened to the project. Projects whose status changed before the Activity section existed still appear in full — that history was carried across.
Programs and portfolios keep no status history of their own, so their Activity sections start from the release that began recording them. A program activated or a portfolio closed before then leaves no entry, and there is nothing to carry across.
Strategic initiatives and status workflows likewise record each kind of change only from the release that began recording it. The one exception is an initiative's creation and deletion, which earlier releases recorded on its portfolio: those entries have been moved onto the initiative.
Planning intervals, PI objectives, risks, scoring models, identity providers, connections and personal access tokens that existed before their changes were recorded begin with a Baseline entry: the record as it stood when recording began. A token already revoked by then has no baseline, since it can no longer change. Locking or unlocking a planning interval's objectives is recorded once, on the planning interval, rather than on each objective.
Where an edit changes several things at once, you see one entry per kind of change rather than one per field: replacing a project's team records a single entry holding the team as it stands afterwards, not one entry per person added or removed. Status changes are the exception, because each transition is its own step — a project imported as Completed shows the moves through Active and into Completed separately, exactly as they happened.