Workflows

Summary

Workflows turn repeatable finance operations into connected triggers, actions, decisions, delays, and human checkpoints. The web app includes a workflow library, a visual editor, and validation and deployment controls. It also includes manual test runs, execution history, and AI tools that help you edit.

Capabilities

With Workflows, users can design and automate end-to-end finance processes visually, using a library of specialized blocks such as triggers, communications, finance actions, flow control, and general actions. The system includes real-time validation, autosave, undo/redo, and version management. Integrated AI tools help suggest and generate improvements to workflow logic. Users can test, deploy, deactivate, or delete workflows, and see a live execution console for individual runs.

Prerequisites

Availability and Access

Workflows need an authenticated team workspace. Starter is the entry plan, so every paid workspace has some workflow capacity.

Plan and role checks protect the current Create Workflow screen. The screen does not show how much of the workflow quota remains. It also does not show a pre-submit limit check. If the number that your workspace can create differs from the configured entitlement, use the workspace’s current billing state and support guidance as the authority.

The primary navigation gate applies to owners:

• workspace owners on Starter or higher can open Workflows from the sidebar;
• members and viewers can see a locked entry, even though the workflow service behind it has narrower namespace permissions for them;
• billing write restrictions can block create, edit, deploy, run, resume, cancel, and delete actions even when read access still works.

The workflow service applies this namespace matrix:

The web navigation itself needs an owner. Use an owner account for the supported browser workflow. A non-owner who opens a direct page can get a locked navigation item or a permission error. This can happen even when the service behind it grants read access.

Concepts

Autosave and Version Behavior

Every document edit marks the workflow dirty. The editor waits 1.5 seconds, then saves the definition and canvas positions. The header reports:

• Saved,
• Unsaved changes,
• Saving…, or
• Save failed.

Command+S or Control+S bypasses the debounce. A run and a deployment also request an immediate save first. When you leave the editor, Eigenn tries to flush the pending work. A browser or network failure can still stop persistence. Do not leave the editor while Save failed is visible.

Generic editor autosaves deliberately keep the current version. The activation action only changes the active state. Because of this, the displayed version does not increment for normal canvas edits. It also does not increment for activate or deactivate in the current web flow.

Workflow

Open Workflows

Choose Workflows in the primary sidebar. The section has five secondary tabs:

See Workflow Outcomes and Workflow Pauses.

Understand the Workflow Library

The Workflows page repeats the outcome cards from Outcomes, so the library opens with the result of the automation rather than a list alone.

Use Search workflows... to match a name, description, or namespace. The filter control can narrow by namespace and active state. The table shows Workflow, Namespace, Status, Nodes, Version, Updated, and Actions.

The page requests at most 100 definitions. Search runs against that loaded set in the browser. It is not an unlimited workspace-wide search.

From a workflow row you can:

• choose Edit to open Workflow Studio,
• choose Activate or Deactivate,
• choose View Details, or
• choose Delete.

Delete needs confirmation. Delete is owner-only. You cannot undo a delete from the web app.

Create a Workflow

1. Open Workflows.
2. Choose Create Workflow.
3. Enter a mandatory Name.
4. Choose a Namespace:
   • Payment Follow-up for receivables follow-up,
   • Promise to Pay for payment-promise operations, or
   • Settlement for settlement negotiation.
5. Add an optional Description.
6. Choose Create workflow.

The new definition starts inactive at version 1. It then opens in Workflow Studio. It contains one Trigger block at the initial position. That trigger defaults to Invoice Overdue. Select it and change the settings when the workflow must start another way.

You cannot change the namespace after creation through the current update service. Choose it deliberately.

Build in Workflow Studio

Workflow Studio has a canvas, a resizable right panel, an optional console, and three panel modes:

• Library lists blocks that you can click or drag onto the canvas.
• Editor sets the name, description, on/off state, and block-specific inputs of the selected block.
• Copilot can explain the open definition, examine history, and propose edits.

Connect a source handle on one block to the target handle on the next. Select blocks or edges to move, change, duplicate, disable, or delete them. When you delete a block, Eigenn also removes the edges attached to it.

The current Library shows these blocks:

The current Library deliberately hides other registered block types. Do not assume that you can add a registered or API-level type through the web editor.

Canvas controls and shortcuts

The canvas supports pan, zoom, partial selection, drag, connection handles, undo, redo, and fit-to-view. Useful shortcuts are:

The editor suppresses shortcuts that change the canvas while the focus is inside most editable fields.

Use the AI Edit Tools

Choose the sparkle icon in the editor header to open Generate with AI. A successful wand request applies its validated proposal immediately as one undoable change.

Open the Copilot panel for a conversational workflow. The server does not apply Copilot proposals. Read the latest proposal. Then explicitly accept or reject it. An accepted proposal is also one undoable document replacement.

AI requests can fail because of connectivity or assistant rate limits. Always examine the new blocks, connections, and settings before deployment.

Validate and Deploy

Choose Deploy to open the deployment sheet. Expand Validation to examine the structural and configuration checks.

Errors such as these block deployment:

• no trigger,
• orphaned or disconnected blocks,
• a cycle,
• a decision branch or router route without a mapped edge,
• an edge that references a missing block, or
• a mandatory block setting that is invalid.

The sheet shows warnings such as a missing terminal block, many triggers, or unreachable blocks. These warnings alone do not block deployment.

Choose Deploy in the sheet to activate a draft. Activation is the shipped publish operation. It saves first. It then checks again on the server. It then sets the definition active. This page has no separate deployment artifact and no environment selection.

The same editor action toggles an already published workflow back to inactive. In that state, the sheet labels the button Deployed. If you select it, the editor calls the unpublish operation. For a clearer deactivation action, open the workflow’s actions menu. Then choose Deactivate.

Run and Stop a Workflow

The Run button stays disabled until the workflow is active. A manual run:

1. saves current editor changes,
2. queues a run with trigger type manual and an empty trigger-data object,
3. opens the console, and
4. overlays live step state on the canvas when realtime data is available.

While that editor-tracked run is active, Run becomes Stop. Stop calls the execution-cancel operation. The web Run action does not ask for trigger data. It also does not send an idempotency key. Do not double-click it. Do not use it as a substitute for a test with an event-specific payload.

When you edit an active definition, the stored definition changes immediately. Eigenn resumes an execution in the Waiting state against the current active definition. If you deactivate a definition, Eigenn skips a resume try. Before a major structural edit, examine Executions for runs in the Waiting state. Then decide how to handle them.

Behavior specification

Workflows persist every change with autosave, displaying save status indicators. Only one namespace can be set during creation, and each versioning/edit action is tracked. Activation makes the workflow eligible for runs, but only correct configurations pass validation and deploy successfully. AI tools offer proposals, but user confirmation is always required for changes. Executions reflect current definition state even after edits, and access is regulated by workspace role and plan. Deleting workflows is irreversible and requires owner confirmation.

Diagrams

Rendering diagram…

Screenshots

Shown with synthetic data in a local workspace.

Verification

Confirm a Deployment

1. Confirm the header badge says Published and the save indicator says Saved.
2. For a safe first test, use a Manual trigger and a no-side-effect path that stops at End.
3. Choose Run once.
4. Watch the console and canvas overlay.
5. Open Workflows → Executions.
6. Open the new run and confirm its status, steps, trigger data, context, and result.

An Active badge proves eligibility to run. It does not prove that an event trigger fired or that an execution completed.

Troubleshoot

Workflows shows a lock

Confirm that the workspace is on Starter or higher. Confirm that you are a workspace owner. A billing write restriction can keep reads available and still block changes.

Create workflow fails for Settlement

Settlement is owner-only. Members and viewers can use only the Payment Follow-up and Promise to Pay namespaces.

Deploy stays disabled

Expand Validation and correct every failed check. Warnings alone do not block deployment.

The editor says Save failed

Keep the page open. Restore network access. Make a small change, or use Command+S or Control+S to retry. Confirm Saved before you run the workflow or leave the page.

Run stays disabled

The workflow is a draft or inactive. Deploy it successfully before a manual run.

A published workflow changed while a run stayed in the Waiting state

The resume worker loads the current definition, not a user-visible immutable deployment snapshot. Examine the execution in the Waiting state and the edited node IDs before you resume it.

The version did not change after an edit or a deployment

That is current generic-editor behavior. Autosave and activation do not bump the displayed version.

1. Open the Workflows section as a workspace owner and confirm you can see the 'Create Workflow' button. (Expect full access if your workspace is on a paid plan and you have owner rights.)
2. Create a new workflow, enter a valid name and select a namespace. (Expect to proceed to Workflow Studio if successful.)
3. Add at least one action and connect it to the default trigger. (Expect valid connections on the canvas.)
4. Choose 'Deploy' and address any listed validation errors until deployment is enabled. (Expect 'Deploy' button to be active after resolving blocking errors.)
5. After deploying, confirm the workflow shows an 'Active' or 'Published' badge. (Expect workflow is eligible for manual run.)
6. Choose 'Run' and observe the execution console and live status overlay. (Expect run status and steps to appear.)
7. Visit 'Executions' and verify this run is listed with correct status and trigger data. (Expect new execution to be visible with expected details.)
8. Attempt to delete the workflow from the library as an owner. (Expect a confirmation prompt and permanent removal after confirmation.)

Related

Related Pages

• Build Your First Workflow
• Workflow Executions
• Workflow Outcomes
• Workflow Pauses
• Monitor and Recover Workflows
• Assistant Automation
• Weekly Finance Ritual