Manage Workflow Data and Execution Logic

Workflows in AI for Process use a central runtime object to store and share data across nodes. This object, called the context object, tracks everything from workflow inputs and node outputs to execution state and environment configuration. Understanding how it works helps you build workflows that pass data reliably, make conditional decisions, and control execution flow.

The Context Object

The context object is a shared runtime container created for every workflow execution. It’s updated continuously as the workflow runs, making data available to each node as it executes.

Every execution has a single context object with three top-level categories:

Category	Key Examples	Description
Run Metadata	startDate, status, flowType, appId, versionId, cfProcessId	Identifiers and timestamps for the workflow instance.
Execution State	steps, branch, activeSteps, status	Progress and outcome data for each node.
Environment & Config	env, agentTimeout, asyncExecDetails	Runtime and environment parameters.

The steps object

The steps object is the most critical part of the context. It’s a map that holds the execution state of every node in the workflow, indexed by node name.

"steps": {
  "NodeNameA": { ... },
  "NodeNameB": { ... },
  "NodeNameC": { ... }
}

Each node’s entry in steps contains:

Field	Description
input	Data received by the node at execution time, produced by previous nodes or user input.
output	Result produced by the node — model outputs, processed data, or API responses.
statusCode / isSuccessful	Whether execution succeeded, failed, or was skipped.
logs	Optional log text or debug messages from the node.
executionTime, totalTime, pausedAt, resumedAt	Node-level timing data for performance analysis.
reqObj / resObj	For AI nodes, the raw request and response envelopes.
metadata	Node-specific information such as schema references, task IDs, or external job handles.

Example node structure:

"steps": {
  "ExampleNode": {
    "input": {
      "parameters": { "param1": "value1" },
      "contextRefs": { "previousNodeOutput": "..." }
    },
    "output": {
      "result": "some value",
      "summary": "optional explanation",
      "structuredData": { "key": "value" }
    },
    "statusCode": 200,
    "isSuccessful": true,
    "logs": "Node executed successfully",
    "executionTime": "1250ms",
    "metadata": {
      "model": "gpt-5",
      "nodeType": "LLM",
      "dependencies": ["SchemaRetriever", "Sanitizer"]
    }
  }
}

How steps evolves during execution

The platform populates steps as the workflow runs:

1. Initialization — The steps object starts empty.
2. Node execution — An entry is created for each node as it runs.
3. Completion — Outputs and timing data are appended.
4. Error handling — Logs and status are updated; branch reflects failures.

---

Input and Output Variables

Workflows let you define named input and output variables that are accessible through the context object for the entire workflow execution.

• Input variables provide initial data to the workflow. They are available immediately after the Start node.
• Output variables store results you want to return from the workflow. You must define output variables explicitly to capture and expose those results.

Access input variables using: context.steps.Start.inputVariable

Set output variables from any node using a context reference. For example, in the End node: {{context.steps.AInode.output}}

Add an input variable

1. On the workflow canvas, click Manage I/O at the top, or click the Start node. The Manage Input & Output dialog opens.
2. On the Input tab, click + Add input variable.
3. Enter a Name (key) for the variable — for example, Product_ID.
4. Select a Type: Text, Number, Boolean, JSON, Remote file, or List of values (Enum).
   • For Text, Number, or Boolean: optionally enable Default value to set a fallback.
   • For Remote file: set a File URL timeout between 5 minutes and 7 days (10080 minutes). Default is 5 minutes.
   • For Enum: click Add Values + to define the allowed values. The system validates inputs against this list at runtime.
   • For JSON: define the schema in the JSON editor. The default value must match the schema, or execution fails.
5. To make the variable required, enable the Mandatory toggle.
6. Click Save.

Add an output variable

1. Click Manage I/O on the canvas. The Manage Input & Output dialog opens.
2. On the Output tab, click + Add output variable.
3. Enter a Name (key) for the variable.
4. Select a Type: String, Number, JSON, or Boolean.
5. Click Save.

You can also add an output variable directly from the End node using the Add a Key option.

---

Referencing Context Data in Nodes

Nodes reference each other’s data using the double-curly {{ }} syntax. This declarative approach resolves values at runtime without requiring code.

Example: Pass the schema output from one node as input to the next.

"steps": {
  "SchemaRetriever": {
    "output": { "schema": [ ... ] }
  },
  "QueryGenerator": {
    "input": {
      "schema": "{{steps.SchemaRetriever.output.schema}}"
    }
  }
}

Supported reference patterns

You can reference any accessible value in the context object:

{{context.appId}}
{{context.steps.QueryGenerator.output.sql_query}}
{{context.schema[0].column_name}}
{{context.steps.Start.variable_name}}

• context refers to the full context object.
• steps provides scoped access to individual node data.
• References work in input fields, API node parameters, LLM prompts, and conditions.

Evaluation behavior

• Lazy evaluation — Values resolve immediately before the node executes.
• Missing keys — If a referenced key doesn’t exist, the expression resolves to null or an empty string in string contexts.
• Circular references — Automatically detected and blocked.

---

Adding and Modifying Context Keys

Beyond declarative referencing, you can extend the context object dynamically using Script Nodes. This is useful for storing computed values, passing control variables between nodes, or preparing data for downstream use. After you add it, any key is available in later nodes using {{context.<key>}}.

JavaScript

// Add a simple key-value pair
context.newKey = "Hello World";

// Store structured data
context.customData = {
  runId: context.cfProcessId,
  stage: "validation",
  timestamp: new Date().toISOString()
};

// Access it in later nodes
console.log(context.customData.stage);

Guidelines for adding context keys

• Use camelCase naming — for example, customerInfo, retryCounter, tempResults.
• Don’t override system-reserved keys: steps, branch, status, dbquery.
• Keep data lightweight — avoid storing large arrays or raw API responses.

---

Storing Structured Data from AI Node Responses

When an AI node returns a structured response, the platform automatically parses it and stores each key individually in the context object. You don’t need to write code to parse or extract values — they’re immediately available to any downstream node.

This works when you attach a response JSON schema to your AI node to define the expected output structure.

How automatic parsing works

1. Define the response schema — In the AI node, attach a JSON schema that describes the keys you expect in the model’s response. For example: scientificname, year, scientist.
2. Model returns structured output — The model formats its response to match the schema.
3. Platform auto-parses the response — Each key from the JSON is automatically extracted and stored in the AI node’s context entry. No manual parsing or Function Node required.
4. Access keys in later nodes — Use context references to retrieve specific values:
   • Full output: {{context.steps.AI0001.output}}
   • Specific field: {{context.steps.AI0001.output.scientificname}}

What you see during execution

When the node runs, the execution view shows:

• Input — The prompt sent to the AI node.
• Response — The raw structured JSON returned by the model.
• Output — The response split into individual keys, each stored separately in the context.

---

Conditional Logic and Execution Flow

The Condition Node routes workflow execution based on whether defined logical conditions are met. It supports three condition types:

• IF — Directs the flow to a specific path when criteria are met.
• ELSE IF — Evaluates additional criteria when the initial IF condition isn’t satisfied.
• ELSE — Defines the fallback path when no conditions are met.

A condition node can be called a maximum of 10 times in a workflow. Exceeding this limit results in an error.

Key capabilities

• Define conditions using context variables, static values, or output from previous steps.
• Combine multiple criteria using AND or OR logic.
• Route execution to different downstream nodes based on condition results.

Common use cases

• Route by classification — Direct flow based on category, type, or priority. For example, route a ticket when priority equals High.
• Fallback logic — Use ELSE to redirect the flow when no match is found.
• Validation checks — Stop or branch execution when required data is missing or invalid.
• Multi-step filtering — Combine conditions for granular control, such as country = US AND status = active.

Configure a Condition Node

1. In Flow Builder, click the + icon on any existing node and select Condition.

2. Click the node to open its properties panel.

3. Set the IF condition:

   • Select a context variable using the {{context. syntax. For example: {{context.ambiguous_sub_categories}}.
   • Choose an operator such as Contains or Equals.
   • Enter a value or another context variable. For example: {{context.steps.Sub_Category_Detection.output}}.
   • Optionally combine criteria using AND or OR.

4. Set routing:

   • Go To — Select the node to execute when the IF condition is met.
   • ELSE — Select the node to execute when the IF condition isn’t met.

If a condition evaluates as true or false but has no connected node, the workflow returns: Path not defined. Please check the flow.

---

Loop Node Context

When a Loop Node executes, it creates its own context object that tracks iteration progress and results. This object is accessible throughout the workflow.

Structure

{
  "loopId": "string",
  "startTime": "timestamp",
  "iterationCount": "number",
  "inputs": ["array of input values"],
  "outputArray": ["array of iteration results"],
  "totalCount": "number",
  "childNodesExecuted": "number"
}

Field	Type	Description
loopId	String	Unique identifier for the loop node, matching the node ID in your flow.
startTime	Timestamp	When the loop started executing.
iterationCount	Number	Number of iterations completed so far.
inputs	Array	The original list of items the loop processes.
outputArray	Array of Objects	Results from each iteration, stored in execution order.
totalCount	Number	Total number of items to process (same as inputs length).
childNodesExecuted	Number	Total count of child nodes that ran across all iterations.

Accessing loop data

Inside the loop — Use special context variables scoped to the current iteration:

Variable	Description
{{context.currentItem}}	The item being processed in the current iteration.
{{context.currentIndex}}	Zero-based index of the current item.
{{context.currentOutput[x]}}	Output from a specific previous iteration.

Outside the loop — After the loop completes, access results using the loop node’s ID:

Variable	Description
{{context.steps.Loop0001.output}}	The complete array of all iteration results.
{{context.steps.Loop0001.output[0]}}	The result from a specific iteration.

Example: Processing a list of email addresses and accessing results.

{
  "loopId": "Add2DB_0",
  "startTime": "2025-11-12T09:23:05.306Z",
  "iterationCount": 2,
  "inputs": ["[e-mail]", "[e-mail]"],
  "outputArray": [
    { "output": { "success": "[e-mail] added to the Employee Database" } },
    { "output": { "success": "[e-mail] added to the Employee Database" } }
  ],
  "totalCount": 2,
  "childNodesExecuted": 10
}

---

Best Practices

1. Use consistent node naming — Names like QueryGenerator or DataCleaner make context references traceable and readable.
2. Prefer declarative references — Use {{context.<key>}} syntax wherever possible. Reserve Script Nodes for computed or dynamic manipulation.
3. Mask sensitive data — Don’t write credentials or PII directly to the context object.
4. Keep context data lightweight — Avoid storing large arrays or raw API payloads. Store only what downstream nodes need.
5. Validate connected paths — Every condition branch must connect to a node. Unconnected paths cause runtime errors.