Monitoring & administration

All administration pages live under Settings → Admin → Workflow and require administrator access.

​

Workflow Definitions

The Workflow Definitions page lists every workflow with its name, ID, status badge (Draft / Published), anchor type, and creation and publish timestamps. Filter by name, status, or anchor type; click a row to open it in the designer.

​

Workflow Instances

The Workflow Instances page searches across every run of every workflow. Filter by:

• Workflow (multi-select)
• Status — Running, Failed, or Completed
• Anchor — document or WorkView, optionally a specific ID (to answer “what workflows touched this document?”)
• Date range

Results show the workflow, the current step (by display name), status, timestamps, and the anchored document or object, loading more as you scroll.

​

Instance detail

Opening an instance shows everything about the run:

• Variables — the instance’s current variable bag
• Live tasks — task transitions currently waiting for a user
• Timers — armed timer transitions and when they fire
• History — the full append-only audit timeline

Each history event records what happened, where (node and action), who caused it (the user, or the service account for automated steps), and when:

​

Handling failures

When an action fails:

1. The instance’s variables roll back to their state at node entry
2. The instance routes to the error node — the node-level override if set, otherwise the workflow-level one — with two variables describing the failure: instance._error.action (which action failed) and instance._error.message (why)
3. If no error node is configured, the instance is marked Failed

A failed instance is never lost: from the instances list you can retry it, or replay it — optionally correcting variables first when bad data caused the failure. The engine does not retry automatically, so design error nodes for the failures you expect (for example, a task transition asking someone to fix a keyword and try again) and use replay for the rest.

​

Environment variables and secrets

The Workflow Variables page manages the configuration workflows reference:

• Environment variables (env.<name>) — plain-text settings such as an SMTP host, shared by all workflows
• Secrets (secrets.<name>) — encrypted at rest, decrypted only at the moment an action parameter is resolved, never written to history, and audit-logged on access. Secrets cannot be used in guards or trigger filters.

Keeping host names and credentials here — rather than hardcoded in definitions — lets the same definition move between environments unchanged.

​

Troubleshooting

​

Where to read next