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 |
|---|---|
| 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.
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.
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.
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, 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.
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, 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)) |
Related documentation
Section titled “Related documentation”- Immutable audit trail - WORM ledger, event sources, and integrity scans
- Security audit (WORM) - ledger categories and review
- Roles and RBAC -
audit_logs_ownandaudit_logs_teampermissions - Exception Management - the shared table, list, and timeline views
- Agent schedules - schedules whose fires trace back to you