Concepts
Core vocabulary for building and operating B3OS workflows.
B3OS workflows are made from triggers, nodes, expressions, connectors, wallets, and durable run state. Understanding these primitives makes the app, API, and action library easier to use.
A workflow is a versioned automation definition. It contains a trigger, nodes, input schema, optional props, visibility settings, and metadata. Drafts can be changed safely; the live version is what triggers and public execution surfaces use.
A trigger is the event source that starts a run. B3OS supports manual, schedule, webhook, blockchain, market, payment, messaging, social, email, and SaaS triggers.
A node is one step in a workflow. Nodes can execute an action, run built-in logic, branch, loop, wait, format data, call a webhook, query an org database, or trigger another workflow.
An action is a typed operation. Catalog actions and built-in actions declare schemas, connector requirements, tags, categories, and outputs.
A connector stores encrypted credentials for a provider such as Slack, Shopify, Gmail, Pipedream apps, Coinbase Business, or other integration systems. Workflows reference connectors by ID instead of embedding secrets.
A wallet is an organization-controlled signing surface used by onchain actions. Wallets can be used for EVM and Solana workflows, subject to connector, policy, gas, nonce, and runtime checks.
A run is one workflow invocation. An execution is one node attempt inside a run. Runs have statuses such as running, waiting, success, failure, and cancelled; executions track node-level status and result.
Props are reusable workflow inputs. Expressions such as {{$props.asset}}, {{$trigger.body}}, {{$nodes.nodeId.result}}, and loop variables inject runtime data while preserving JSON types.
Lifecycle Terms
| Term | Meaning |
|---|---|
| Draft | Editable workflow definition that is not yet live |
| Live version | Published definition used by triggers, schedules, public runs, and API execution |
| Validation | Schema and graph checks performed before testing or publishing |
| Test run | Controlled run with provided input for debugging |
| Publish | Promote a draft into the live version |
| Pause | Stop automatic execution while preserving the workflow |
| Rollback | Restore a previous live version |
Organization Terms
| Term | Meaning |
|---|---|
| Organization | Workspace boundary for members, workflows, connectors, wallets, keys, usage, databases, and knowledge |
| Role | Permission bundle such as owner or developer |
| API key | Scoped machine credential for REST API access |
| Service account | Non-human identity for automated access patterns |
| CU | Compute unit used for usage accounting and workflow execution cost |
| Org database | Managed table storage that workflows can query and update |
| Org knowledge | Searchable knowledge used by Caddie for context-aware workflow creation and debugging |
Execution Statuses
| Object | Statuses |
|---|---|
| Workflow | draft, active, paused, archived |
| Run | running, waiting, success, failure, cancelled |
| Execution | pending, running, success, failure, skipped, waiting, scheduled, cancelled, auto_swapping |
Node IDs become part of expression paths. Rename titles freely, but keep stable node IDs when other nodes reference their outputs.