RumataBuild and run workflows
Connect steps into a repeatable process, from the first event to the final result.
Step-by-step guidance.
Before you start
- A project with workflow allowance.
- Permission to view, edit, or run the workflow for the action you intend.
- Deployed activities or configured integrations for any steps that need them.
What is a workflow?
A workflow connects steps into a process. A trigger starts it; each following step works with data, calls a service, makes a decision, or waits. For a client request portal, a workflow might receive a request, validate it, save it, and return a confirmation.
The workflow definition describes the steps in your process. A run is one execution of those steps. Edit the definition to change the process, or inspect a run to understand what happened.
Start with a manual example
- Open Workflows in your factory’s product tools, then choose an existing workflow or create one in the editor.
- Begin with a Manual Trigger so you can supply harmless sample input.
- Add one transformation, such as Edit Fields (Set), before connecting external services. Connect the trigger output to the next input.
- Select each node to review and complete its configuration. Check required values and validation messages.
- Review the configuration before selecting Save. For an existing workflow, Save publishes a new graph version. Use the editor’s Run controls with safe input and inspect each node’s result before adding more steps.
Choose the right kind of step
| Node | Purpose |
|---|---|
| Manual Trigger | Start a run yourself with supplied input. |
| HTTP Trigger | Start from an inbound request. |
| Schedule Trigger | Start on an interval or cron schedule. |
| Activity | Call a deployed reusable backend operation. |
| HTTP Request | Call an external API directly. |
| Code | Transform data with sandboxed JavaScript. |
| Edit Fields (Set) | Set or transform fields. |
| AI Agent | Use a model with configured activity tools. |
| If / Switch | Choose a branch based on data. |
| Filter / Merge / Wait | Select items, combine paths, or pause the process. |
Understand a result
- Open the run result or timeline and find the first failed step.
- Inspect the data entering that step. Confirm expected fields and values exist.
- Read the step error. Check configuration, permissions, service availability, and allowance before changing the graph.
- Make a focused fix for the cause, then rerun with the same safe input.
- Check the final output and the actual side effect, such as the saved record. A completed node does not prove the business result was correct.
Workflow version history keeps earlier definitions. Execution history keeps run evidence. They have separate retention and capacity limits, so old definitions and old run details may disappear on different schedules.
Move from a manual test to automation
Once the manual test works, configure your HTTP or schedule trigger. For an existing workflow, Save publishes a new active version when the graph changes. Confirm the saved version and schedule status before enabling external callers. Unsaved canvas changes stay separate from the active graph.
For automated actions, decide what should happen if a request arrives twice, a service times out, or a field is missing. Connect error paths where they are supported and make failures visible.
Frequently asked questions
Is Save just saving a draft?
For an existing workflow, Save publishes the changed graph as a new active version. Review any HTTP or schedule trigger and its downstream actions before saving. Unsaved canvas edits are not the active version.
What is the difference between a workflow and a run?
The workflow is the definition: the steps and their connections. A run is one execution of that definition. Use the editor to change the process and Runs to understand a particular execution.
Why did a completed run not create the expected record?
Completion reports execution status. It does not verify your business outcome. Inspect the input and output of the write step, then check the actual record and target database. A successful call can still use an unintended value or destination.
Will retrying a workflow repeat external actions?
A new run may repeat writes or external requests that already succeeded. Inspect the previous run before retrying. For actions that must happen once, design a duplicate-detection or idempotency rule rather than relying only on the run status.
Technical reference
Ports and transformation input
Trigger nodes expose an out port. Activity and HTTP nodes expose in, out, and error. If nodes route to true or false; Switch has a default branch plus configured cases. Connect the intended port rather than assuming every output is success.
// Code node: $ is the input; $nodes contains upstream outputs.
return {
title: String($.title ?? "").trim(),
status: "open"
};Execution accounting and limits
One admitted top-level manual, HTTP, or scheduled invocation is one workflow execution. Child workflows, node attempts, and retries inside it do not independently create extra top-level executions. An admitted failed or cancelled run still consumes an execution; a pre-admission rejection does not.
Safety guardrails also bound attempts, concurrency, payloads, processing, and total lifetime. A durable wait is not an unlimited run. Do not design a workflow that depends on retrying forever.