Introduction to Workflows

​

What is the workflow engine?

The workflow engine moves documents and business objects through configurable, auditable processes. With workflow management permission, you design a workflow once — events then start instances automatically, actions run without user involvement, and human decisions surface as tasks in users’ inboxes. A workflow is built from a small set of concepts:

• Definition — the workflow itself: a named, versioned graph of nodes and transitions
• Anchor — what the workflow operates on: a document, a Caseflow object, or System for work without one content item as its anchor
• Scope — the document types, or the application and class, the workflow is allowed to touch
• Triggers — the events that start an instance (for example, a document is created or its keywords change)
• Nodes — the steps of the process; each node can run actions when an instance arrives
• Transitions — the edges between nodes; fired automatically, after a timer, by a user completing a task, or after a batch Join condition
• Actions — the side effects: update keywords, send an email, add a note, run a script, start another workflow
• Instance — one run of the workflow for its document, object, or system process
• Tasks — the human decision points; they appear in the Tasks page as buttons, optionally with a small form
• Interaction rules — questions asked before a document is stored; the answer starts the workflow named in the rule and seeds its variables

​

How a workflow runs

1. A matching event arrives, a published system schedule fires, or an authorized manual start is requested
2. The engine starts an instance at the workflow’s initial node (only one active instance per workflow per document/object)
3. The actions on the node’s Actions tab run
4. The engine evaluates the node’s transitions: automatic transitions fire immediately when their condition passes, timer transitions fire after a delay, task transitions wait for a user, and Join transitions wait for a batch condition
5. The instance moves from node to node until it reaches a terminal node and completes

If an action fails, the instance routes to a designated error node — or is marked Failed and can be replayed by an administrator.

​

User surfaces

​

Access and administration

Use workflow-engine.view to inspect definitions, schedules, and instances, and workflow-engine.manage to build and publish workflows and operate schedules. workflow-engine.admin includes these capabilities and instance-variable administration. Task visibility and completion depend on the task’s configured access; they are separate from authoring access. Running a workflow document action needs no workflow permission, while configuring one needs workflow-engine.manage. Before enabling a process, verify its triggers, scope, service-account access, task groups, and failure path. For system schedules and child batches, also review Schedules and batch workflows.

​

Where to read next