Activity feed

A workspace where both people and agents make changes all day needs a place to answer one question: what just happened here? The activity feed is that place. It is a readable, newest-first view of the changes across your workspace, who did what, to which record, and when, so you can catch up on a morning's worth of motion at a glance rather than piecing it together from a dozen records.

This page is about that feed: what a row tells you, how you narrow it, and how it relates to the two systems next to it. The activity feed is not your notifications, which come to you about the work you watch or own; it is the workspace's recent changes, all of them. And it is not a separate record from the admin Audit Log; it is the same trail, shown through a lighter lens. You reach it at Settings → Activity.

What the activity feed shows

The feed opens under the header Activity with the subtitle Recent changes in your workspace, a search box, and a newest-first list of entries. Each entry is one change, and it carries enough to understand the change without opening the record:

• Who made it, as an avatar and a name.
• What kind of change it was, as a coloured badge: Created, Updated, Deleted, Restored, Assigned, Revoked, and the like, green for creation, red for deletion, blue for an update, so the nature of a change reads at a distance.
• Which record it touched, by type (an initiative, a plan, a role, a member) and by name. The common types read as friendly labels; a less common one shows its plain type name, so nothing is ever hidden behind a missing label.
• A short summary where there is one, and the field-level changes underneath, the values that moved from one thing to another.
• When, as a relative time that ages from minutes to hours to days.

Narrowing it works the way the rest of the platform's lists do. Search matches the record name, the summary, the person, the type, and the action across the entries you have loaded. The filters group them three ways, by action (just the deletions, say, or just the assignments), by entity type (only the plans, only the roles), and by user (only what one person changed). You can flip the sort to oldest first, and pull in older entries with a Load more button at the foot of the list. When there is nothing yet, the feed says so plainly, Actions you and your teammates take will be recorded here.

The feed works on the entries in front of you. Search and the filters narrow what you have loaded, and the count at the top tracks that same set, so a glance at the feed is always a glance at one coherent slice of recent motion. Load more widens the slice when you want to reach further back, and for a filtered look across the entire record at once, the Audit Log queries the whole trail at the source.

The feed is a snapshot you refresh when you want it, not a stream you watch, which is exactly right for a catch-up view: you read a settled picture of what has happened rather than chasing a moving one. New changes land in the trail as they happen, and you bring them into view by reloading or loading more.

Sarah Chen starts her Monday in the activity feed. She filters by entity type to plans, then by user to the engineer who owned Friday's release, and a weekend's worth of changes on the Insights project reads in under a minute, each row's field-level diff telling her what actually moved before she opens a single record.

What shows up here

The feed is fed by the workspace's audit trail, and the trail records far more than the planning work most people picture. Knowing the range matters, because the activity feed is often the first place an administrator or a security owner looks to answer "what changed, and who did it." The changes that land here group into a few kinds.

• Planning work. Initiatives, plans, projects, goals, and key results, as they are created, updated, deleted, and restored. This is the day-to-day motion most people open the feed for.
• Membership and access. People invited, joined, or removed; their roles changed; the workspace itself set up or torn down; roles assigned and revoked; and licensing changes. The record of who can do what, and how it shifted.
• Security events. The platform's guardrails at work: a permission checked and denied, a credential lease through its full life from request to grant to expiry, a managed command run or held back, a sandbox kept from an environment value outside its allowance. Every moment the platform enforced a rule is recorded alongside the work itself, so you read what was protected in the same place you read what was done.
• Agent authoring. The lifecycle of the things that shape how agents behave: skills, agent instructions, MCP server configurations, sandbox profiles, and flows, as they are created, updated, deleted, or rejected at a checkpoint.
• Structure. Portfolios, teams, sprints, and workflows, and the links between them, as they are built and changed.

The throughline is that one trail carries all of it. A plan moving to blocked, a role being revoked, and a credential lease being denied are different kinds of event, but they are recorded the same way and read in the same feed, so the answer to "what happened in this workspace" lives in one place.

When a credential lease is denied during Sprint 24, the person who owns security does not have to go hunting. They open the activity feed, filter the action down to the denial, and the row names the person, the lease, and the moment it was refused, sitting in the same trail that carried the plan edits beside it. One feed answers both "what shipped" and "what was held back."

One trail, two lenses

The activity feed and the admin Audit Log read from the same record. Every change in the workspace is written once to a single tenant-wide audit trail, and these two surfaces are two ways of looking at it. The difference is the lens, not the data.

The activity feed, under Settings, is the approachable one. It is built for catching up: avatars, coloured action badges, the fields that moved, search and the three filters. It is the view you open to see what your teammates and agents have been doing lately.

The Audit Log, under Platform, is the forensic one. It is the same entries with the tools an investigation or a compliance review needs: a tab that isolates AI-authored skills, a Source filter that splits human edits from agent ones, the entity identifiers and content hashes that pin a change down, and a CSV export for taking the record elsewhere. Where the activity feed is for reading, the Audit Log is for proving.

The one thing the Audit Log keeps to itself is the apparatus for telling human edits from agent ones: the AI mark, the Source filter that splits the two, and the content hashes that anchor a change. The activity feed names whoever the entry records as having made the change and leaves the forensic distinctions to the Audit Log, which is the right division of labour: catch up here, investigate there. For the full model, what is captured, how an entry is shaped, the retention, and the export, the audit trails concept is the deep reference; this page is the day-to-day window onto it.

Who can see it

Because the activity feed shows the whole workspace's changes, seeing it is governed by the same scope as the Audit Log: audit.read. That scope sits with the Owner and Admin roles, and with the Billing Manager, and with any custom role an administrator grants it to.

The gate is enforced where it counts, on the data. The Activity entry in Settings is visible to everyone and the page opens for anyone, but it is filled by the server, and the server returns the workspace's activity only to a caller whose role carries audit.read. For anyone without it, the server returns nothing, and the page rests at the same calm "No activity recorded yet" a brand-new workspace shows, never an error and never a half-filled list. The feed is a window for the people responsible for the workspace, and because the gate sits on the data rather than the door, it holds the same whoever opens the page.

The split between the two scopes is the same split between the two lenses. Reading the trail, in either view, takes audit.read. Taking it out of the product as a file takes audit.export on top, an entitlement-gated action that lives only on the Audit Log. The activity feed never exports; it is for looking, and the looking is what audit.read grants.

How far back it goes

The feed reaches back as far as the workspace's audit trail keeps its record. By default that is the last 365 days: entries older than a year age out, which keeps the trail to a useful, recent window rather than an ever-growing pile. A workspace that needs to hold its record longer, or indefinitely, can have the retention extended, since the trail is the same one the Audit Log exports for a review. Retention is a property of the trail itself, so it applies to both lenses at once: what has aged out of the activity feed has aged out of the Audit Log too, and what the Audit Log can still export is what the feed can still show.

Why the activity feed works this way

A single record with two lenses is a deliberate choice. The alternative, a separate "activity" store kept apart from the audit log, would mean two things to trust and two things to keep in step, and the day they disagreed you would not know which one was right. Writing every change once, to one tenant-wide trail, and then presenting it two ways means the friendly view and the forensic view can never tell different stories. The activity feed is the audit log, made easy to read.

Keeping the same scope on both lenses follows from the same honesty. The activity feed shows the whole workspace's changes, so it is governed like the thing it shows. It would be a quiet leak to let a friendlier presentation widen who can see the trail; instead, the lighter lens carries the same gate, and the only thing the Audit Log adds on top is the export that takes the record out of the product. What you can see is what your role lets you see, in whichever view you open it.

For a team lead, the activity feed is your morning catch-up. Filter to your team's plans or to one person's changes, and a week's worth of motion reads in a minute, with the field-level changes telling you what actually moved.

For an engineer, it is the fast answer to "did that go through, and who touched it after me." The same record as the audit log, pared to what you want when you are just checking: who, what, and when.

For an administrator, it is the readable companion to the Audit Log. The same trail you would export for a review, in a form you would actually scan day to day, gated by the same audit.read so there is one answer to who can see the workspace's changes.

For the person who owns trust, the activity feed is evidence that the friendly view and the forensic view are the same record. There is no second log to reconcile, no presentation that widens access, and when you need to tell a human edit from an agent's, the Audit Log carries the source mark over the very same entries. The window is easy to look through and gated exactly like the thing behind it.