Core Concepts

Understanding these concepts is essential before working with apptor flow. Each concept maps directly to something in the platform — a data entity, a runtime construct, or a UI element.

---

Workflow (Process)

A workflow (also called a process in the API) is the top-level unit of automation in apptor flow. It is a directed graph of nodes connected by flow links.

Key properties:

• Has a name, description, and unique ID
• Belongs to an organization
• Has one or more versions (see Version Management)
• Has an active version deployed per environment
• Can be executed via the API or the designer's Run button
• Can be published as a public URL

Analogy: A workflow is like a function in code. Its definition is the source code; each execution is a function call with its own isolated state.

---

Node

A node is a single step in a workflow. Every node has a type that determines what it does and what properties it accepts.

Nodes are categorized as:

• Flow Control — Start, End, If/Else, Split, Loop, Call Process, Subprocess
• AI — AI Task, Voice Task, Memory Action, Tool nodes
• Integration — REST API, Email, SMS, SQL, Domain Task
• Logic — Script Task, Set Variable
• Human — Input Node, Output Node

See the Node Reference for complete documentation of every node type.

---

Connection (Flow Link)

A connection is a directed edge from one node to another. Connections have a type that controls routing:

Connection Type	Used On	Meaning
sequenceFlow	Most nodes	Standard "next step" connection
trueFlow	If/Else node	Taken when condition evaluates to true
falseFlow	If/Else node	Taken when condition evaluates to false
successFlow	Nodes with error handling	Taken on successful completion
errorFlow	Nodes with error handling	Taken when node throws an error
timeoutFlow	Nodes with timeout config	Taken when node exceeds its timeout
toolConnection	Tool nodes → AI Task	Links a tool to the AI agent that uses it

Connections can have a JUEL condition expression applied to trueFlow and falseFlow connections. The condition is evaluated at runtime: ${variableName == 'value'}.

---

Variable

A variable is a named value that flows through the workflow execution context. Variables are created by nodes (as outputs) and consumed by nodes (as inputs or in property expressions).

Two syntaxes exist — using the wrong one is the most common mistake:

Context	Syntax	Example
Node property values (prompts, subjects, bodies, etc.)	{variableName}	Hello {customerName}
If/Else and Loop condition expressions	${expression}	${issueType == 'critical'}

Variable features:

• Nested access: {customer.address.city}
• Environment variables: {env.API_KEY}
• Any node property that accepts a string accepts {varName} interpolation
• Variables are scoped to the execution instance — different executions have isolated state

See Variable Reference for the complete guide.

---

Execution (Process Instance)

An execution is a single run of a workflow. Every time a workflow is triggered, a new execution is created with its own isolated state.

Each execution has a unique ID, tracks which workflow version ran, records all variable values, and has a status (running, completed, failed, cancelled).

Each node in the execution tracks its individual status, variables, and timing.

---

Trigger

A trigger is the mechanism that starts a workflow execution. Triggers are managed via the Triggers tab in the designer.

Trigger types include:

• API call — explicit POST request with input data
• Webhook — an inbound HTTP request starts a workflow
• Schedule — time-based triggers (via the scheduler module)
• Event — an intermediate catch event that wakes a suspended workflow

---

Organization (Tenant)

An organization is the top-level multi-tenancy boundary. All data — workflows, executions, users, API keys, secrets, integrations — is scoped to an organization.

Organization hierarchy:

Organization
├── Users (with roles and permissions)
├── Workflows
├── Executions
├── API Keys
├── Integrations / Connections
├── Secrets
└── Environments (DEVELOPMENT, PRODUCTION)

---

Environment

An environment represents a deployment context within an organization. The two built-in environments are DEVELOPMENT and PRODUCTION.

• Every workflow version belongs to one environment. Draft versions live in DEVELOPMENT; Published versions live in PRODUCTION.
• Publishing is a single action — it promotes the current draft to PRODUCTION and automatically creates a new draft in DEVELOPMENT for further work.
• Webhooks, scheduled triggers, and API calls (without an explicit version) always execute the Published (PRODUCTION) version.
• API calls can target a specific environment via the environment query parameter.

See Version Management for the full publish workflow.

---

Permission

Permissions control what users and API keys can do within the platform. They follow the format RESOURCE_ACTION (e.g., WORKFLOW_EXECUTE, USER_CREATE).

Permissions are assigned to roles, and roles are assigned to users and API keys. See Authentication for the full permission reference.