Workflow Nodes
Workflows are built by connecting a series of nodes on the workflow template canvas. Each node represents a distinct step or activity in the process. The following is an overview of node types available in Docwize.
Workflow Canvas
Workflow Template Canvas
Start Node
Start Node
The start node is the first node in every workflow. It triggers the workflow and connects to subsequent nodes. It cannot be deleted.
Node Descriptions
Nodes are accessed from the Nodes tab in the left panel of the workflow canvas. Drag a node onto the canvas to add it to the workflow. Alternatively, right-click anywhere on the canvas to open a context menu and select a node.
Nodes tab
Right-click context menu on the workflow canvas
User and Role Management
| Node | Description |
|---|---|
| List of Users | Identifies the recipient(s) of the action request from among verified Docwize users. |
| Initiator | Identifies the recipient of the action request as the person who initiated the workflow. |
| Custom Field Email | Identifies the recipient(s) of the action request based on email addresses populated in a custom field. |
| Custom Field User | Identifies the recipient(s) of the action request based on users populated in a custom field. |
| Generate User | Creates a new billable Docwize user. |
Action Requests
| Node | Description |
|---|---|
| Varies | These nodes create action requests for end users. They take user nodes as inputs to define who should action the request. For an in-depth look at Action Request nodes and Action Request Configuration nodes, see the Action Request section. |
Settings
| Node | Description |
|---|---|
| Duration Node | Sets the due date for the action request, in number of workdays. |
| Capture Customfields | Prompts capturing of content added to a custom field when a user completes an action request. Specific fields can be configured as read-only (visible but not editable) or hidden entirely for users completing that step. |
| Capture Standard Fields | Prompts capturing of standard document detail fields. |
| Capture Virtual Interface | Prompts users to complete a configured Virtual Interface (a custom form or view) as part of the workflow step. |
| Workflow Initiation Input | Indicates the conditions required to trigger the initiation of the workflow. |
| Workflow Runtime Input | Allows the workflow initiator to select the recipient of the next action request at runtime, rather than using a preconfigured recipient. |
| Office Online Review | Adds a button that opens the workflow document in Office Online. |
| Enable Review | Allows the recipient of the action request to add annotations to a document. |
| Review Action | Enables the recipient to complete an action request on annotations made during the workflow. For example: User 1 annotates a document — "This bathroom door hits the toilet. The design doesn't work." User 2 then receives the annotation for approval. |
| Review Action Reply Filter | Filters annotations based on status or another marker — for example, only approved annotations may proceed. |
| Attachment Config Node | Configures rules for document attachments. |
Tools & Tasks
| Node | Description |
|---|---|
| Conditional Node | Defines conditions that must be met before the workflow can proceed to the next step. |
| Webhook Node | Pauses the workflow until the webhook is triggered by an external API. |
| API Node | Sends an API request to an external API. Includes an Auto Retry option — see below. |
| GitHub Action Node | Dispatches a GitHub Actions workflow run against a connected repository. See below. |
| GitHub Commit Node | Commits selected document(s) to a connected GitHub repository. See below. |
| Run Oliver Node | Runs a configured Oliver agent headlessly as a workflow step. See below. |
| Excel Import Node | Imports an Excel file into Docwize. |
| CSV Import Node | Imports a CSV file into Docwize. |
| JSON To Dataframe | Converts JSON data into a structured dataframe (tabular format) for use in downstream processing nodes. |
| CF Insert Node | Performs bulk insert, update, or delete operations on custom field grid tables using data from a source dataframe. |
| Extract Tables | Extracts content into tables. |
| Extract to Standard Fields | Extracts content into the standard document metadata. AI prompts and relevant fields can be configured to guide the extraction. |
| Split Pages | Splits document pages at selected points. |
| Extract to Customfields | Extracts content into custom fields. |
| Link Extraction | Links extracted content to other records or documents. |
| Extract to Grid | Extracts content into a grid. |
| Translation Task | Translates document content from the source language into a selected language. |
| OCR Task | Runs OCR on documents, converting images of text into machine-readable text format. |
| SP Task | Triggers the selected SP task. |
| Extract Attachments | Extracts attachments from documents. |
| Index Task | Indexes documents. |
| Scan Request Node | Connects a barcode or QR code scanner to the workflow. Useful for workshops and warehouses. |
| Trigger Node | Triggers a configured action when this point in the workflow is reached. |
| Custom Field Input Calculation | Calculates and populates custom field values based on a configured calculation, using inputs such as document templates, tags, or user fields. |
| Position Extraction Node | Extracts text from a fixed position on the page. Works well for documents where codes appear in the same location on every page, such as delivery notes. |
| Split PDF Node | Splits PDF pages into individual pages or smaller chunks. |
| Convert to PDF | Converts the workflowed document to PDF format. |
| Complete Task | Marks all steps in the workflow as completed. |
| Output Node | Defines the reply options available to the recipient of an action request. |
| Sub Workflow Node | Links a sub-workflow within the current workflow. |
| Generate PDF From Template | Generates a PDF using a preconfigured document template. |
| Generate Document From Template | Generates a document using a preconfigured document template. |
| Generate Attachment Node | Generates a document as an attachment using a preconfigured template, rather than as the main workflow document. |
| Custom Field Locks | Locks custom field content entered by a user during an action request, preventing further editing. |
| Subject Change Node | Changes the workflow subject at a specific point in the workflow. |
| Description Update Node | Updates the description of the workflowed document at a specific point in the workflow. |
Conditional Node — checkbox field comparisons
When a Condition rule compares a Checkbox-type custom field, the value selector offers Yes / No options instead of a free-text box.
API Node — Auto Retry
The API Node includes an Auto Retry section. When enabled, a failed request is retried automatically instead of failing straight away, spreading retries out over time with a randomised, decaying delay. When retries are exhausted, any configured Failure Routes take over.
API Node — Auto Retry settings
| Setting | Description |
|---|---|
| Enable auto retry | Turns on automatic retry behaviour for this node. |
| Retry on | Which failure types trigger a retry: Timeout, HTTP error status, Null / empty response, Other errors. |
| Max retries | The maximum number of retry attempts. |
| First retry delay | How long to wait before the first retry. Retries are checked on a 5-minute schedule, so delays are chosen in 5-minute steps; the first retry happens at the next check after the chosen delay has elapsed. |
| Delay decay factor | Multiplier applied to the delay between successive retries. |
| Max delay | The upper limit on the delay between retries. |
| Jitter (0–1) | How much the delay is randomised. 1 spreads retries fully across the window so items that failed together do not all retry at the same instant; 0 uses a fixed delay. |
GitHub Commit Node
The GitHub Commit Node commits one or more documents to a connected GitHub repository. It requires the connector's contents_write feature to be enabled (and workflow_files if committing under .github/workflows) — otherwise the run is refused.
GitHub Commit Node — Repository and branch settings
| Setting | Description |
|---|---|
| Repository | The connected GitHub repository to commit to. |
| Branch | The branch to commit onto. Supports Jinja templating against the source document. |
| Base branch (optional) | When the branch does not exist yet, it is forked from this branch. Defaults to the repository's default branch if left blank. |
| Create branch if missing | Creates the branch when it does not exist. If off and the branch is missing, the node fails. |
| Delete branch on completion | Deletes the branch once the downstream GitHub Action run finishes — useful for cleaning up throwaway branches. Requires a GitHub Action Node in poll or webhook mode after this node. |
| What to commit | Selects which document(s) this node commits (see below). |
| Repository path (optional) | Subfolder in the repository to place the file(s) under. Left blank, files commit at the repository root using each document's original filename. |
| Commit message (optional) | Overrides the default commit message. Supports Jinja templating. |
What to commit offers three options:
What to commit — selector options
| Option | Description |
|---|---|
| Workflow document | The item this workflow started from. |
| Node input | Documents produced by previous nodes. |
| Specific document IDs | A comma-separated list of document IDs to commit. |
GitHub Action Node — Run Tracking
The GitHub Action Node dispatches a GitHub Actions workflow run and, depending on the selected Run Tracking Mode, can wait for that run to finish before proceeding. It requires the connector's actions feature to be enabled, otherwise the run is refused.
| Setting | Description |
|---|---|
| Repository | The connected GitHub repository. |
| Workflow File | The workflow filename in .github/workflows on the chosen ref. It must declare a workflow_dispatch trigger and a docwize_run_id input, and echo it via run-name so Docwize can identify the run. |
| Ref (branch or tag) | The branch or tag to dispatch against. Supports Jinja templating. |
| Workflow Inputs | Extra workflow_dispatch inputs passed to the run. Values support Jinja templating and are rendered at dispatch time. A docwize_run_id correlation token is added automatically. |
| Run Tracking Mode | Fire and forget (dispatch and continue immediately), Poll for completion (pause and poll the Actions API until the run finishes), or Await webhook (pause and resume when GitHub delivers the workflow_run completion webhook; a watchdog poll recovers missed deliveries). |
If the target workflow file is unlikely to support run correlation, a pre-flight warning appears in the dialog:
Pre-flight warning: run tracking may not work for this workflow
To poll or await a run, the workflow file must declare a workflow_dispatch trigger, declare a docwize_run_id input, and echo it into its top-level run-name (e.g. run-name: "${{ inputs.docwize_run_id }}"). Without the run-name echo, Docwize cannot correlate the run and the node hangs until it times out. Fire and forget mode is unaffected.
Run Oliver Node
The Run Oliver Node runs a configured Oliver agent headlessly as a workflow step. Oliver runs unattended with a fixed workflow-safe tool profile — no chat, no surfaces, no delegation — regardless of the chosen agent's own tool list. The result is written to the output custom field.
Run Oliver Node — agent and prompt settings
Run Oliver Node — output and branch fields
| Setting | Description |
|---|---|
| Agent | The configured Oliver agent to run. A Create agent link opens the Agent Configurator if a new agent is needed. |
| System prompt injection (optional) | Jinja-templated instructions injected into the system prompt for this run. |
| Prompt | The Jinja-templated user turn. Supports tokens such as {{ document.description }}. |
| Context documents (optional) | Comma-separated document IDs or Jinja tokens attached as context for the run. |
| Run as | The user identity the run executes as. Defaults to Workflow initiator. |
| Timeout (seconds) | Maximum run duration before the node routes to failure. Between 30 and 3600 seconds. |
| Output custom field | The custom field that receives Oliver's summary text. Read it downstream as {{ custom_fields.<field_name> }}. |
| Branch custom field (optional) | Custom field that receives a parsed branch label, for use by a downstream Conditional Node. |
The node routes to On success or On failure depending on whether the run completes within its timeout.
System & Flow Control
| Node | Description |
|---|---|
| And Node | Requires all recipients of the action request to complete it before the workflow proceeds. |
| Cancel Node | Proceeds as soon as one recipient completes the action request, cancelling all outstanding copies for other recipients. |
| Placeholder Node | Passes the workflow to the next step without any checks. Useful for accelerating task-only pipelines. |
| Status Update Node | Updates the workflow status to reflect the most recently completed action request. Place this node after an And, Cancel, or Placeholder node. |
| Lock Node | Locks the workflowed document, preventing updates to its document details. |
| Calculate Routing | Uses a configured approval matrix to calculate which users should receive a node. |
| Input Checker | Validates whether specified inputs meet configured criteria. Routes the workflow to a Satisfied or Not Satisfied output path depending on the result. |
| Distribution Node | Distributes workflow items to external users or contacts. Recipients do not need to be Docwize users. |
| Distribution Group Node | Distributes workflow items to a configured group of users and contacts. |
| Distribution Set Node | Distributes to a whole set of distribution groups at once, splitting members into action-request recipients and contacts. See below. |
| Email Notification | Sends an email notification to specified recipients when this point in the workflow is reached. |
| Consolidated Notify | Sends a single consolidated email to each recipient, batching all pending notifications into one message rather than sending multiple individual emails. |
Distribution Set Node
The Distribution Set Node distributes workflow items to a whole set of distribution groups at once. It splits each group's members into internal users, who receive an action request, and external contacts, who receive a document package by email.
| Setting | Description |
|---|---|
| Distribution Groups | The distribution group(s) this node sends to. |
| Select groups at workflow start | When enabled, the workflow initiator chooses the distribution groups at runtime instead of using a fixed selection. |
| Email Mode | Email per action request (a separate email per action request) or Rolled up per user (one summary email per user covering all their action items). |
| Same email for every action request and contact | When enabled, uses a single template for every recipient instead of mapping templates per action request. |
| Default Email Template | The template used when no per-action-request template is mapped. |
| Contact Email Template | The template used for external contacts. |
| Email Template Per Action Request | Maps a specific email template to each action request. |
| Default Action Request | The action request used for group members who don't match a more specific mapping. |
| Burn in Annotations | When enabled, annotations are flattened into the document before it is sent. |
Related configuration
- Building Workflow Templates — the canvas where nodes are assembled into templates
- Action Requests — detailed configuration of action request nodes
- Workflows overview — introduction to workflow configuration