User actions
A user action is a process node waiting for a structured human interaction: enter information, confirm reading, choose an option, or complete a step in a dedicated experience. The node defines the orchestration contract; the User Journey is one surface capable of presenting this interaction.
An explicit wait point in the process
The node creates or reuses a pending action. The user's response completes this action, produces node outputs, and lets the process continue.
When a node genuinely needs interaction, Ormuz materializes a
process_user_action attached to the instance and current node. While that action remains
pending, the instance waits for its resolution rather than treating the node as complete.
If the same step is reevaluated while an action pending already exists for this node and instance, Ormuz reuses it instead of creating a second one. Hybrid nodes may also finish immediately when no interaction is needed; in that case no durable wait is imposed on the participant.
The node belongs to the process definition. The process_user_action is the observable fact created during an instance. The User Journey is an interface capable of presenting the action to the participant. Do not confuse these three levels.
Action lifecycle
| State | Meaning |
|---|---|
pending | The interaction is still open. This is the only state in which a response may be submitted. |
completed | The response was validated and recorded; node outputs are available for process continuation. |
cancelled | The action was interrupted without a usable response, for example because the interaction failed or the instance was stopped. This state therefore does not by itself mean the instance failed. |
Completing an action emits process.user_action.completed. Cancellation must not be interpreted as a user decision: it only indicates that this interaction can no longer be completed in its current state.
Actions Core
Ormuz currently provides 16 user actions. This page groups them by intent; their exact parameters, outputs, and routes remain documented on node pages.
Collect information
Simple inputs or forms whose response becomes a typed node output.
Obtain a decision
Interactions that directly produce a graph route from the participant's choice.
Present information
Reading or acknowledgment steps that do not invent an additional business decision.
Verify or continue elsewhere
Verification or navigation interactions whose outcome remains observable by the process.
An extension may provide a specialized action node — payment, signature, KYC, bank verification, etc. The Orchestration page intentionally remains generic: see the node page under Integrations for the provider-specific contract.
Routing actions do not need a separate gateway to express their decision. For example,
collect_choice directly produces the routes corresponding to its choices, and
accept_terms exposes the routes
accepted / refused.
Persisted Form or dynamic form?
| Need | Node | Output contract |
|---|---|---|
| Reuse a Form schema known at design time | custom_form | form_id, values |
| Build questions during execution | dynamic_form | values |
custom_form references a reusable Form resource. dynamic_form receives a common.form_spec at runtime, then freezes that specification in the action: submission is validated against the snapshot actually presented to the participant. The dynamic form creates no temporary Form resource and does not re-emit its specification in outputs.
Collected data and protection
Values submitted through an action retain the classification from their contract and sources. A sensitive or secret value therefore remains protected when it becomes a node output or is wired to later steps.
Observability surfaces mask protected values by default. This does not prevent a downstream node from using them when the process explicitly passes them and its authority permits it.
See Data protection in processes for propagation, downgrade, and targeted-reveal rules.
User Journey
The Ormuz User Journey can present the action currently intended for the participant, collect their response, and continue the journey without a custom frontend. It exposes only data required for the authorized interaction.
The Console exposes these actions for observability and can open the participant's User Journey, but it does not complete the interaction itself. The public API process-user-actions remains a read surface: the participant response passes through the User Journey to preserve the same presentation, validation, and participant-access contract for every action type.
An interaction may confirm that the user saw a screen, selected an option, or was redirected. It does not prove that a payment, signature, or operation performed in an external system actually succeeded. Use the provider contract or corresponding business event for that guarantee.
Human approval ≠ user action
An internal approval uses the canonical
approval_request and its
approval_assignment model. It may suspend a process like a user action, but it represents an aggregated decision by designated approvers, not an interaction by the current participant in their hosted journey.
Keep these models separate: user action for participant interaction; approval request for an internal human decision with its own aggregation policy, deadline, and approvers.
Process resumption
When an pending action is completed, its output becomes the output of the corresponding node and the process continues the graph from that step. Nodes already completed before the wait are not replayed merely because a user response arrives.
For a routing action, the selected route is part of the node result itself. Unselected branches remain unexecuted, with the same binding consequences as other routers. See Routing and decisions.