Skip to content
Back to

Activity log

The Activity log records every tracked change in your workspace, whether a person or an AI agent made it, and links each change to the activity that caused it. You explore it in Flow under Audit logs → Activity, or per workflow in the workflow editor’s Activity panel. Every activity is also written to the immutable audit trail.

What is recorded

Section titled “What is recorded”

Fontana records an activity whenever a person or an agent makes one of these changes, on both the Flow UI path and the agent tool path:

Area Examples
Workspaces Workspace edits; runs started, succeeded, and failed
Data and Knowledge Graph Data uploads; Knowledge Graph file uploads (one activity per upload batch)
Agents Agent created; requests to an agent, handoffs, and sub-agent calls; email sent by an agent
Schedules and triggers Agent schedule activated or fired; workflow trigger created or fired
Exceptions and documents Exception raised, updated, closed, or reactivated; status, severity, and assignee changes; comments; workflow document edits
Administration and security Roles, users, and team membership; models, MCP connections, and external agent connections; BYOK keys, email relay, embedding, and backup restore

Each activity carries a short summary and a reason when one applies, so you can read what changed without opening the underlying record. Summaries name what changed rather than that something changed: a workflow save reads as Updated workflow: renamed “Quarterly close” to “Month end”; 2 nodes.

Where a change has a field-by-field record, the activity detail also shows a Changes list: each changed field, what it was, and what it became. Workflow saves compare the saved configuration against the previous one, match nodes and edges by their identity rather than their position, and leave out moves on the canvas that change nothing about what the workflow does.

Initiator chain

Section titled “Initiator chain”

Every step that leads to a change is its own activity, linked to the activity that caused it. Suppose your colleague asks Agent X to update a workflow. Agent X hands off to Agent Y, which calls Agent Z as a sub-agent, and Agent Z edits the workflow. The log records four linked activities:

Your colleague asks Agent X          (owner: your colleague)
  → Agent X hands off to Agent Y
    → Agent Y calls Agent Z as a sub-agent
      → Agent Z edits the workflow   (actor: Agent Z, owner: your colleague)
  • Actor is who performed that step: here, Agent Z.
  • Owner is the person accountable for the whole chain: here, your colleague. Filtering on your colleague as owner returns the workflow edit that Agent Z made.
  • Scheduled work traces back to the person who set it up. Activating an agent schedule or creating a workflow trigger records an activity by you, and every fire links to it, so the runs and changes a schedule causes are owned by you.
  • Agent canvas work traces back to the agent that proposed it. When an agent edits a workflow on the canvas and you accept or merge those edits, the resulting activity links to the agent’s turn, so a workflow an agent built is distinguishable from one edited by hand.

Every activity in one chain shares a correlation id, set when the chain starts and carried by every step below it. The same id appears on the matching lines in the immutable audit trail, so you can follow one chain from the Activity log into your compliance evidence.

Conversation steps such as agent requests, handoffs, and sub-agent calls are hidden in the All changes view. Use Chains to read a chain in place, or Everything to see every activity.

Where to find it

Section titled “Where to find it”
  • Audit logs → Activity (/audit-logs/activity) shows the activity log for your whole workspace, within your permissions.
  • Activity panel in the workflow editor’s right toolbar shows the activity of that workflow only. The workflow scope is applied by the server, so it stays in place whichever view you pick.

Views and detail

Section titled “Views and detail”

The Activity log uses the same view model as Exception Management:

  • Views: table, list, timeline, JSON, and Details. The defaults are All changes (a table of changes, newest first), Chains (the same table with the conversation steps kept, so a chain reads in order), Timeline, and Everything (every activity). JSON shows the loaded page as read-only text. Details shows a row list beside the selected activity. Each view has a header title and description you can edit, and you can hide that header.
  • Sort: by time, newest or oldest first.
  • Columns: Initiated by shows the activity that caused each row, so you can see the chain without opening a row. Correlation id is available as a hidden column when you need to match a row to your audit trail.
  • Filters: on kind, actor, owner, initiated by, correlation id, target, outcome, and your custom properties.
  • Custom properties: add your own properties, such as a review status or a note, and set their values on any activity.
  • Display: format a date or number from its property settings, and set conditional formatting on a view, the same way as in Exception Management.
  • Comments: discuss an activity in Markdown comments beside it.
  • Detail: select an activity to see its properties, its initiator chain from the first step to this one, what it caused, the fields it changed, and its comments.
  • Walk the chain: select any step under Chain or Caused to open that activity. This is how you follow a chain end to end, because the conversation steps between changes are hidden in the All changes view and cannot be found in that list. When the activity you open is one the current view shows, the table highlights it too.

Comments and custom property values sit beside an activity; they never change the activity itself.

Who can see what

Section titled “Who can see what”

Access follows your role’s permissions. See Roles and RBAC for the permission catalog.

Permission What you see
audit_logs_team:read Every activity in the workspace, and you can edit the shared views and custom property definitions
audit_logs_own:read Activities whose chain you started (you are the owner)
workflows:read with read access to a workflow That workflow’s activity in its Activity panel

Views and custom property definitions are shared across the workspace, so only audit_logs_team:read holders change them; everyone else switches between them. Anyone who can read an activity can comment on it and set its custom property values. When a chain leads back through an activity you cannot read, the detail shows that the chain continues outside your access.

Relationship to the immutable audit trail

Section titled “Relationship to the immutable audit trail”

Each activity is recorded in the same transaction as the change it describes. After that change commits, Fontana writes one line per activity to the immutable audit trail, carrying the activity, its actor, its owner, its links in the chain, and the chain’s correlation id. Because every step of a chain shares that one id, the ledger lines for a chain group together. A change that does not commit records neither an activity nor a ledger line.

Surface Role
Audit logs → Activity Explore, filter, annotate, and trace changes in Flow
Immutable audit trail Tamper-evident, append-only system of record for compliance evidence (see Security audit (WORM))
Section titled “Related documentation”