Workflows
Docwize workflows automate document-centric processes by connecting reusable human actions, system tasks, integrations and routing logic into a versioned workflow template.
Configuration is split across several surfaces:
| Area | Purpose |
|---|---|
| Actions | Define reusable Action Requests and their reply options. |
| Templates | Build, version, group, secure, test and enable workflow templates. |
| Nodes | Configure assignments, processing tasks, integrations and flow-control behaviour. |
| Forge | Upload tenant-defined functions that become workflow nodes. |
| Review Setup | Define review programmes and the automatic rules that start them. Shown to users with Documents - Manage Review Schedules. |
Open workflow configuration from New → Workflow Setup.
How workflow configuration fits together
A workflow template consists of:
- Template metadata — name, type and optional scope.
- Builder graph — visual nodes, edges, positions and sections.
- Compiled workflow model — persisted node inputs and outputs used by the execution engine.
- Template lineage — immutable saved versions of the workflow.
- Availability/security — enabled state plus template-group visibility rules.
The builder is therefore more than a diagram editor. Saving publishes a new executable template version.
Recommended configuration order
- Create Action Requests and their reply options.
- Create template groups and apply user/group security where required.
- Create the workflow template and configure its scope.
- Add and configure nodes.
- Connect every execution branch.
- Save and confirm a new version is created.
- Test using the template card's dedicated Test action.
- Enable the workflow family for normal starts.
Testing is not a rollback sandbox
The dedicated Workflow Test Runner exercises a workflow using test context, but authors must still treat it as capable of real side effects.
Configured API calls and data updates can execute during a workflow test. Use safe test documents, endpoints and data.
For normal end-user launch routes, see Testing and Launching Workflows.
Version model
Normal builder saves create a new template version. Existing workflow instances remain pinned to the template version they started with.
This means:
- changing a template does not silently alter already-running workflow instances;
- the Versions tab can be used to inspect previous graphs;
- saving an older graph creates another newest version instead of rewriting history.
A separate live node edit capability exists for intentional in-place changes to supported node inputs on an already-used template version. This is controlled separately because its blast radius can include multiple running workflows.
Template groups and security
Templates can be organised into nested groups.
A group can restrict visibility to explicit users and/or groups. If no security is configured on the group, it is visible to otherwise-authorised users.
Deleting a template group ungroups its templates; it does not delete those templates.
Key permissions
| Permission | Purpose |
|---|---|
| Workflows - Create | Start workflows on documents where the user is otherwise allowed to do so. |
| Workflows - Create Template | Author and publish workflow templates. |
| Workflows - Monkey Patch | Change supported node settings in place on an existing template version used by live workflows. |
| Workflows - View All | View workflows beyond the user's normal participation scope where applicable. |
| Workflows - Revoke Any | Revoke workflows beyond the user's own initiations where applicable. |
| Workflows - Modify Action Recipient | Change action recipients. |
| Workflows - Assign External | Assign supported workflow actions to external recipients. |
| Replay Workflow | Retry/replay supported workflow processing. |
| Undo Actions Taken | Undo supported completed actions. |
See Permissions for the tenant's complete permission set.