How actions work
Actions are the side effects of a workflow. You define them once in the definition’s Actions tab, then reference them from a node’s On Enter chain or from a transition’s action chain. Chains run in order; if an action fails, the instance’s variables roll back to their node-entry state and the instance routes to the error node (or is marked Failed). A few conventions apply across the catalog:- Value parameters accept expressions. Anything marked expr below can be a literal, contain
{{ references }}, or be switched to expression mode and computed with a formula like$instance.retries + 1. - Actions target the anchor by default. Document and WorkView actions accept an optional
DocumentId/ObjectIdparameter; leave it empty to act on the workflow’s own document or object, or supply an expression (for example an ID read from a keyword) to act on a related document or object. The accompanyingTargetDocumentTypeId/TargetClassIdsetting tells the designer which type the related target is, so its pickers offer the right keywords or attributes — it has no runtime effect. - Some actions capture output. Actions with an
IntoVariableparameter store their result as an instance variable for later steps to read asinstance.<name>.
Keyword actions (document workflows)
Document actions (document workflows)
WorkView actions (WorkView workflows)
Variable actions
The email Body field uses the template editor with
{{ }} autocomplete, so you can mix prose with references:
Workflow control
Scripts
To pass a structured input, write an object literal in the formula editor:
Where to read next
References & expressions
How to write the values, conditions, and templates these parameters accept.
