Skip to content

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.

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
Workflows Workflow 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.

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.

Conversation steps such as agent requests, handoffs, and sub-agent calls are hidden in the default change views. They appear when you walk a chain or when you view every activity.

  • 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.

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

  • Views: table, list, and timeline. The defaults are All changes (a table of changes, newest first), Timeline, and Everything (every activity, including conversation steps).
  • Sort: by time, newest or oldest first.
  • Filters: on kind, actor, owner, 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.
  • 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, and its comments.

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

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.

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, and its links in the chain. 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))