Exception management

When a validation or transform fails, you choose whether the run records a normal audit error or a durable exception you can triage later. Exceptions are distinct from canvas audit Warnings and Errors: they persist in the Workspace and appear on Exception Management (?view=exceptions).

Exception Management is one setup and one ticket store per Workspace, like a Problems tab for everything you build there. Each ticket names the workflow it came from, so the Workspace view lists every exception and a workflow view shows that workflow’s own.

The settings live in the Workspace at .fontanaexceptions.json, beside .fontanaconfig.yaml. Tickets, comments, and history are append-only files under .fontana/exceptions/. Both travel with the Workspace, so a restore point or a copy of the namespace carries your exceptions with it. You edit the settings from the screen below, and Fontana writes the ticket files for you: each change is appended, so the history of a ticket stays complete.

On error configuration

On an operation badge (and on node execution settings) you set On error:

raise error - existing audit error path for the run
raise exception - writes an audit row with reserved type exception, then Fontana records a ticket in Exception Management when the build finishes

You also set exception type (label), message, and severity. Severity is a text field: a level from 1 to 5, or a template that uses a column on the failing row. You can add other exception fields, such as status and assignee, the same way. Those values are stored when the exception is first created. The info icon beside each added field explains an example that uses this operation’s columns. The default exception type for an operation is {action} {type} issue (for example arrayLengthLessThan validation issue). For a node without an operation context, the default is {nodeType} issue.

Exception Management views

Open Exception Management from the workspace sidebar. The Workspaces explorer lists one Exceptions entry for the Workspace itself: it opens the same screen over every workflow in that Workspace, with a Workflow column you can show on any view. Hover Exception Management or a named view under any workflow in the Workspaces explorer and choose the star, or Pin to header on the row menu, to pin it for everyone in the workspace. That pin opens that workflow’s Exceptions. The tab stays in the header on every Workspaces pane. That header is favourite tabs only. The same pin label shows on every Workspaces pane, including the alias you set. Opening a file or folder does not add a Workspace tab. When Exception Management is open and is not starred yet, that page stays as the active tab, and the star on that tab pins it for the workspace. Opening Exceptions underlines this pin, not the workflow file, even when both are starred. Double-click a pinned tab to set a display name for everyone in the workspace. When you open the workflow as a file, More file views includes Exceptions. When the workflow has tickets, Exceptions sits on the file-view strip with an amber count of those tickets. The count matches the Exception Management total, and it shows 99+ above 99. Choosing Exceptions opens Exception Management for that workflow. The folder uses ?view=exceptions. Each named view (Table, Board, Timeline, and views you add) uses ?view=exceptions&exceptionViewId= plus that view’s id, so you can bookmark or favourite a specific layout. The page shares one explorer: title, stats tiles, view tabs, and the table, board, or timeline body. Named views live on the Workspace: table, board, list, calendar, timeline, JSON, Details, and Chart. Every workflow in the Workspace offers the same views, filtered to that workflow. You can create, rename, duplicate, reorder, and delete views. Each view has its own layout, which properties it shows, and its own filter, sort, and group. Each view also has a header: a title, a short description, and optional status tiles. You edit those under Header in view settings, and you can hide the header. View changes save to the Workspace’s Exception Management settings as you make them. Use the sliders control on the toolbar for view settings (layout, property visibility, filter, sort, conditional formatting, group, and header) and Exception Management property schema in one menu. In All Properties, a date or number has a format control. A date takes the patterns you accept and the pattern you show. A number format names the preset and shows its pattern: General (1300), Number, 2 decimals (1,300.00), Number, 1 decimal (1,300.0), Integer (1,300), Percent, 2 decimals (0.00%), Percent, 1 decimal (0.0%), Whole percent (0%), or Scientific (1.30E+03). The format you choose stays on that property. Conditional formatting in view settings opens Edit formula for that view, the editor the Formula operation uses. You write one formula: setStyle("Message", "background", "amber") styles one field, setRowStyle("bold", true) styles the whole row, and setProp("Message", …) changes only the text a field shows, while sort, filter, search, grouping, and export keep the stored value. Fields are named as the view shows them. A condition can be any formula over the row, including a comparison between two fields, for example if(prop("Status") == "Raised", setRowStyle("background", "amber")); write starts with and ends with as test(prop("Message"), "^Timeout") and test(prop("Message"), "failed$"). Styles are a light or strong background, text colour, bold, italic, underline, strikethrough, large or small type, each border side, a colour dot, and an icon from the asset library. optionColor("Status") gives the colour of the option a row holds, and me() gives your own name. When two statements set the same style, the later one wins. A row style shows through a field with no style of its own, and the row selection tints over both. The preview paints the loaded rows as you type and lists any row whose formula fails; that row shows without styles and every other row still paints. A formula with errors paints nothing until you fix it. In Property visibility, drag a property by its grip, type icon, or name to reorder columns for that view. Hide stays a separate control. When a list in view settings has more than ten items, a filter appears at the top of that list. Your last-selected tab is personal to you; it is not shared with the team.

On a node’s Explore tab, a bottom pane starts as a tab strip along the bottom of the editor. Exceptions stays idle until you open it. A count on the tab shows how many tickets that pane will list. When the count is zero, the collapsed tab is faded. Click the tab to open the list, and click it again to close it. Drag the tab up or down to resize the list. The view toolbar sits on the right of the tab. Select a data cell and the pane shows the tickets for that row. View settings on that pane include Upstream exceptions. It starts on, so the pane also lists tickets from the nodes and rows that produced the selected rows; turn it off to see this node’s tickets only. A cell whose data traces back to the column an earlier node flagged shows a hollow orange ring in the same mark as this node’s own exception; a ticket raised on the whole row marks every cell of that row. A filled orange dot is still this node’s exception, and it stays when the row has both. Hover the ring to read the ticket: its severity and message, the node and operation that raised it, the upstream row and column, and its status. With no row selected, that option covers every row of the port. The choice stays on the open editor. It is not saved with the view. The tab strip then reads how many exceptions that selection lists, with the selected-row count in a pill. The AI chat composer shows that row and that column with the node and the port. Remove the Row chip or the Cell chip to list every ticket for the node again. Column, filter, and sort changes on that pane are shared across every node in the Workspace. That pane’s view stays off the Exception Management tab, the sidebar, dashboards, and analysis view names.

The Exceptions view icon shows a count pill for active open exceptions and uses the colour of the worst open severity. That wash and count stay visible while Exception Management is the selected view. Severity colour comes from ticket levels 1-5. The pill shows 9+ when more than nine tickets are open.

Table

The default table is one row per ticket. Columns follow that view’s shown properties. You can wrap cells, freeze leading columns, resize data columns (including Status, Assignee, and Severity), and edit writable properties inline. The Inactive column shows a broken-link mark when a ticket has no matching row in the loaded data, and the agent’s face on that row. Hide it in view settings under Layout, in the Table section, with Inactive column. Board, list, and timeline still show that mark on the row. Select and Actions stay a fixed width. The footer downloads the rows loaded in that view as CSV or JSON. CSV uses the labels in the grid. JSON matches the JSON view, with each row id and the stored values. The file includes the shown data columns. Use the leading Select checkbox to pick rows on the current page. When two or more rows are selected, a compact Selection strip appears on the view toolbar with a Bulk Edit menu (aggregate property fields, and moving every ticket in one value group at once), configurable quick action chips, and a clear control. Actions include View (opens the Exception panel), Resolve, and Close.

Board

A board groups cards by a status, select, or people property. Drag a card between columns to update that property on the ticket. If the view has no group property yet, the board asks you to pick one. Column headers can add, rename, recolour, and reorder options for status and select properties.

List

A list is a compact vertical list: title plus shown properties. You can optionally group rows; group headers collapse.

Calendar and timeline

A calendar places tickets on a month grid by a date property you choose (Calendar by). Days without a date go to an Unscheduled tray. In view settings, Text length sets how many characters each chip title and shown value keeps. It starts at 20. A timeline places a bar from a start date to an optional end date (Timeline by), with day, week, and month zoom. If the date binding is missing, the view opens and asks you to pick the date property.

JSON and Details

JSON shows the loaded page of tickets as read-only text. Details shows a row list beside a full page for the selected ticket: its properties and its history. Property visibility controls which fields appear on each row. All Properties controls which fields appear on the detail page.

Chart

A chart counts or sums the tickets in the view by one property: status, assignee, severity, type, a date, or any custom property. Pick vertical or horizontal bars, a line, a donut, or a single number. A date property buckets by day, week, month, or year. Group by adds a series breakdown on bars and lines. The chart respects the view’s filter, labels select, status, and people values by name, and updates as tickets change.

Exception panel

On Exception Management the workflow right toolbar shows Triggers, Audit log, and Developer Tools. Overview, Nodes, and Operations stay off that rail. Exception and AI Chat stay off the rail on every view. An open toolbar pushes the workflow header. Header AI Chat (sparkles) opens in its own column. On a wide workspace view, pin AI Chat to keep that column beside an open tool panel. The pin appears in the AI Chat header when the view has room for both panels. The pin starts off: opening AI Chat closes the open tool panel, and opening a tool panel closes AI Chat. Until you resize AI Chat, it matches the tools sidebar width. Home, Knowledge Graph, and Admin Header AI stay a single dock.

In the table, click Message, Type, or another surface cell (not Status, Assignee, or Severity) to select that ticket. The Exception panel opens when auto-open is on (the default). With auto-open off, the selection stays and the panel stays closed. Tick the row checkbox the same way. Two or more checkboxes switch the panel to bulk mode with a count in the header. Status, Assignee, and Severity stay dropdowns so you can change those fields without opening the dock.

On board, list, calendar, or timeline, click a card, row, chip, or bar to select the ticket. The Exception panel opens when auto-open is on. With auto-open off, the click selects the ticket and leaves the panel closed. View in Actions still opens it. The header control uses a sidebar icon. Its tooltip states whether auto-open is on, what a selection does, and what a click will do.

For one ticket, the panel shows schema-visible properties (system, origin, and custom) in schema order, excluding rows you mark default hidden in All Properties, plus Comments (append-only GitHub Flavored Markdown via Add comment; History renders that source) and History (status, severity, assignee, comments, and agent email). An agent that emails about the ticket names that ticket on the send. History adds an Email sent row for that ticket, and the reply adds an Email received row on the same ticket and continues the agent’s chat thread. Both rows show the mail itself: subject, sender or recipients (never Bcc), and the plain-text body, with Expand email on a long message. See Agent email. Comment rows show the commenter on the timeline (user, agent, or agent with a user badge). Captions read Comment added by the operator, or Comment added by the agent on behalf of the operator. Use Collapse and Expand on the History heading to switch compact density. Each History change is also recorded in the Activity log. Quick actions in the panel header come from Exception Management settings (defaults include Resolve and Close) plus Show on canvas.

For multiple tickets, Properties show aggregate rows: a count pill beside each value (always the number of selected tickets with that value, never ALL). Click a value to facet-filter the other properties. You can select more than one value in the same property. Values that no longer match stay visible at count 0, greyed out, and not clickable. Header quick actions run the same presets with an all suffix (for example Resolve all), skipping tickets where that action is disabled. Bulk property editing for checkbox selection also lives in the view-toolbar Bulk Edit menu; the panel does not show History in bulk mode. The bulk editor ends with Delete beside Apply. Delete asks you to confirm, then removes the selected tickets from every view and count. Their history stays in the Workspace, so the record of what was deleted and by whom is kept. A later build can raise the same exception again as a new ticket. The activity log records each permanent delete.

Message is the raised exception text; it does not change when you add a comment. Enable the read-only Last comment system property in view settings when you want the newest comment body in table, board, or filters. Lineage stays on canvas Overview.

Resolve and Close update the ticket’s status option (defaults include Raised, Investigating, Awaiting review, Resolved, Closed, plus options you add in Exception Management settings). Assignee is a member of the Workspace. Unassigned cells show a dash. Assignment is stored on the ticket and survives reload. If that person later loses access to the Workspace, the cell still shows their name; the picker lists current members plus Unassigned only.

Properties and origin rows

Exception Management settings manage typed properties (text, number, select, status, date, people, checkbox, url, email) for the whole Workspace. System fields (message, status, assignee, severity, type, workflow, identity keys) stay first-class. Originating-row snapshot keys appear as origin properties you can type, show, and order.

Stored ticket values are never rewritten. A ticket reads its values through the settings as they are now, so a value whose property you retyped or deleted shows empty, and the other values on that ticket keep their meaning.

Columns that come from a ticket’s stored originating-row snapshot keep a Status-coloured left accent on the raising field. Presence (active / inactive) is machine-owned. Status is yours.

When the first Schema on a lineage defines a row identity key, builds match the same ticket by the workflow it belongs to plus that key:

A new key inserts a ticket.
A key still raising this build updates the snapshot and leaves the Status you set.
A key missing from this build’s exception set becomes inactive. It stays in its Status with a broken-link mark. Hover the mark to see that the exception has no matching row in the currently loaded data. Resolved plus inactive stays in Resolved.
If that key raises again, the same ticket becomes active and keeps your Status.

Matching covers the nodes that ran in this build, so a node whose result was reused unchanged keeps its tickets active. Renaming or moving the workflow file moves its tickets with it, and they keep their status, assignee, and comments.

The first build after you define a Schema key does not rematch older tickets that used a full-row content hash; those become inactive and current-build exceptions insert as new tickets.

Open Exception Ticket Persistence from the Workspaces explorer (Community chip, Financial) to walk this loop on a five-row trade blotter keyed by tradeId. Quantity and notional validations raise exceptions. You can Resolve a ticket, edit or delete that trade in Static Data, and re-run to see the same ticket stay, become inactive, or reactivate with the Status you set.

Exceptions in dashboards

Dashboard Markdown and Stat blocks render Jinja templates against live workflow data. They read the rows a build published through {% query %} blocks (Published data), and alongside those a template can read this workflow’s exceptions through exceptions.

Expression	What it returns
`exceptions.rows`	Every exception of this workflow.
`exceptions.views["Table"].rows`	The rows of that named view, after the view’s filter and sort order.
`exceptions.viewNames`	The names of the Workspace’s Exception Management views.

Each row carries message, type, status (the option id), statusName (the label you see in the table), open, severityLevel, nodeId, nodeTitle, workflowPath, assigneeName, createdAt, lastSeenAt, and lastCommentBody. source holds the originating row keyed by column, and properties holds your custom properties keyed by property name. Select, status, multi-select, and people properties read as their labels.

Count exceptions in a sentence or a Stat block:

{{ exceptions.rows | selectattr("open") | list | length }} open of {{ exceptions.rows | length }}

Render a view as a table. Keep the for and endfor tags on their own lines so each exception becomes one table row:

| Node | Message | Status | Severity | Assignee |
| --- | --- | --- | --- | --- |
{% for r in exceptions.views["Table"].rows -%}
| {{ r.nodeTitle }} | {{ r.message | replace("|", "\\|") }} | {{ r.statusName }} | {{ r.severityLevel }} | {{ r.assigneeName or "Unassigned" }} |
{% endfor %}

Add a column from the originating row with r.source["tradeId"], or from a custom property with r.properties["Team"].

The editor suggests exceptions, its members, and your view names as you type. A view name that matches no view, or more than one view, shows an inline template error at that spot and the rest of the document still renders. Give each view a distinct name to reference it. PDF, DOCX, and XLSX downloads render the same template.

Agent tools

When you assign the Workflow capability on an agent, that agent can list, read, and update Exception Management tickets, and can change the Workspace’s Exception Management properties and views. Pass the Workspace (projectBucket in chat User context JSON) as bucket. Access follows Workspace read and write permission; these tools are not gated by data-query or workflow-config chat flags. The two setup tools, workflow_getExceptionManagement and workflow_updateExceptionManagement, also take path: a workflow file in that Workspace (projectPath in chat User context JSON, or a ticket’s workflowPath). Your access to that workflow decides whether the agent may read or change the setup.

Tools name an assignee, and a value of a people property, by that Workspace member’s principal id, which workflow_getExceptionManagement lists in its assignee pool. The id stays the same after the workspace is restored from its Fontana Files, so assignments keep naming the same people.

When an agent schedule fires on exception_raised or exception_status_changed, User context includes selection.exceptionIds and exception.exceptions for every ticket in that batch. A build that raises many tickets starts one turn, and each change starts at most one turn.

When you select one or more tickets in Exception Management (open ticket or table checkboxes), new AI chats also receive selection.exceptionIds. The AI Chat composer shows a chip with each ticket’s message (not the ticket id). Hover the chip for Chat context: plus the kind and full message. Use workflow_getException with each id.

Tool	What the agent can do
`workflow_listExceptions`	Bounded summaries (default 25 tickets, maximum 100) with optional filters for workflow path, status, node, type, and severity. Each row includes the status option id and display name. The list does not return originating-row snapshots.
`workflow_getException`	One ticket, property values (the Actions column is table chrome and is omitted), append-only comments, history, and the Workspace’s status options. Pass both `bucket` and `exceptionId`. A mismatch or missing read access returns empty.
`workflow_updateException`	Writable ticket fields: status option (id or name), severity 1-5, assignee (a member’s principal id or null), custom properties, and an optional append-only comment. Unknown statuses are rejected with the available options. Only this ticket changes.
`workflow_getExceptionManagement`	The Workspace’s Exception Management properties, named views, assignee pool (each member’s principal id, name, and email), and the settings version to send back on a write. Pass `bucket` and `path`. Use this before you change setup.
`workflow_updateExceptionManagement`	Ordered edits to properties and views (add, rename, retype, delete, reorder, configure show/filter/sort/groupBy). Pass `bucket` and `path`. You cannot delete system properties or the last view. A write against a stale settings version is rejected.

See Tools and MCP for how you assign built-in tools.

Activity log - exception changes alongside every other tracked change, with the same views
Workflow orchestration - pipeline model and execution engine
Operation node - transforms and validations on rows
Schema node - row identity key that Exception Management uses to match tickets across runs
Tools and MCP - built-in workflow_* exception tools on the Workflow capability tile