Skip to main content

Activity Feed

The activity feed is the audit trail for collaboration events in your organization. It records the moments that matter for compliance and oversight -- who shared what, who installed which template, who was added or removed, and which credentials changed -- so you have a single place to answer "what happened and when?"

Where to find it​

The activity feed shows up in two places:

  • Inside a project -- the project detail page shows the recent events relevant to that project (shares, template installs, runs).
  • Org-wide -- admins see an org-wide stream that aggregates events across every project.

# TODO screenshot: Project detail page with the activity feed panel visible, showing 3-5 recent events

What gets recorded​

Each event captures four pieces of information: what happened, on which resource, by whom, and when. Recorded events include:

  • Shares granted and revoked -- when a project, workflow, or trigger is shared with someone (or unshared)
  • Members added and removed -- including who the heir was when a member was removed
  • Templates installed -- which template, by whom, into which project, from platform or org
  • Ownership transfers (coming soon) -- when a resource changes hands without a membership change
  • Credential changes -- when shared credentials are added, modified, or deleted

Workflow runs themselves are not in the activity feed -- those have their own dedicated history under each workflow's Runs tab. The activity feed is specifically for collaboration events.

Who sees what​

The activity feed is visibility-filtered. You only see events about resources you have access to.

  • You see every event about your own resources, plus events about resources that have been shared with you, plus org-wide events (like member additions).
  • Admins see everything in the org, because admins have audit-view across all resources.
  • You do not see events about other members' private resources you have no relationship with.

This means the feed never leaks information about private work, even at the metadata level.

Why the feed exists​

The feed isn't just nice-to-have -- it's part of the platform's audit posture. Concretely:

  • Incident response -- when something unexpected happens (a workflow was unshared, a credential changed), you can see exactly when and by whom.
  • Onboarding context -- new admins can scroll back and learn how the org has evolved.
  • Compliance evidence -- shared SOC 2 / audit posture benefits from a tamper-resistant log of consequential actions.

You don't need to do anything to enable it. Every consequential action is logged automatically.

Reading an event​

Each entry shows:

  • Event type -- e.g. "Workflow shared", "Member removed", "Template installed"
  • Subject -- the resource the event happened to, with a link to it
  • Account -- the member who performed the action
  • Timestamp -- relative ("3 hours ago") and absolute on hover

Some events have extra context: a workflow share event includes the recipient's name and the view mode (Inspector or Runner); a template install records whether it came from the platform marketplace or the org marketplace.

# TODO screenshot: close-up of two or three activity feed entries with different event types

What's not (yet) in the feed​

The feed deliberately stays focused on collaboration events. The following live elsewhere:

  • Workflow run history -- on the workflow's own Runs tab
  • Document changes -- in the project's Documents view
  • Knowledge graph edits -- in the knowledge graph viewer
  • Login / authentication events -- in account security settings

If you need a unified view across all of these, the feed plus per-area history covers it; we don't merge them into one chronological stream because the noise floor would drown the signal.

Learn more​