Execute Workflow Node

The Execute Workflow node invokes another CogniAgent application within your workflow. This enables modular design where complex logic can be encapsulated in one application and reused across many others.

When to Use

Reusable logic - Encapsulate common workflows (email parsing, data validation) and call them from multiple places
Complex sub-processes - Break large workflows into manageable pieces
Team collaboration - Different team members can own different workflows
Versioning - Update a shared workflow without modifying every workflow that uses it
Separation of concerns - Keep workflows focused on one responsibility

Think of Execute Workflow like calling a function in programming. The called workflow is the function, and your inputs are the parameters.

Example: Lead Qualification Pipeline

A main workflow that uses specialized workflows for each step:

Receive the lead

Use a Webhook node to receive new lead data from your website form.

Enrich the lead

Execute Workflow: Lead Enrichment Workflow

{
  "email": "{{webhook_1.body.email}}",
  "company": "{{webhook_1.body.company}}"
}

This workflow looks up company info, social profiles, and tech stack.

Score the lead

Execute Workflow: Lead Scoring Workflow

{
  "enrichedData": "{{execute_workflow_1.result}}",
  "source": "{{webhook_1.body.source}}"
}

This workflow applies your scoring model and returns a score.

Route based on score

Use a Condition node to route high-score leads to sales, others to nurture campaigns.

Workflow structure:

├── Webhook (receive lead)
├── Execute Workflow (Lead Enrichment Workflow)
├── Execute Workflow (Lead Scoring Workflow)
├── Condition (score > 80?)
│   ├── Met: Integration Action (create Salesforce opportunity)
│   └── Unmet: Integration Action (add to nurture campaign)

Example: Document Processing Hub

A central workflow that routes documents to specialized processors:

├── Webhook (receive document)
├── Read File (extract content)
├── LLM (classify document type)
├── Multi-Condition (based on document type)
│   ├── invoice: Execute Workflow (Invoice Processor)
│   ├── contract: Execute Workflow (Contract Analyzer)
│   ├── resume: Execute Workflow (Resume Parser)
│   └── default: Execute Workflow (Generic Document Handler)
└── Integration Action (store results)

Each specialized workflow handles its document type with custom logic.

Example: Approval Workflow

Use workflows to encapsulate approval processes: Main workflow:

├── App Trigger (new purchase request in Slack)
├── Execute Workflow (Expense Approval Workflow)
│   Input: {amount, requestor, description, receipts}
├── Condition (approved?)
│   ├── Met: Integration Action (process payment)
│   └── Unmet: Integration Action (notify requestor of rejection)

Expense Approval Workflow:

├── Start
├── Condition (amount > 500?)
│   ├── Met: Human Step (manager approval required)
│   └── Unmet: LLM (auto-approve with policy check)
└── Return result

Passing Data

Input Arguments

The target workflow declares its input arguments on its Start node. In the Execute Workflow node you map a value to each argument — values can use {{...}} expressions resolved from the current execution:

Argument	Value
`customerId`	`{{webhook_1.body.customerId}}`
`items`	`{{webhook_1.body.items}}`
`priority`	`high`

The called workflow receives these as its starting input.

Receiving Results

The called workflow’s output becomes available as {{execute_workflow_1.result}}:

Customer name: {{execute_workflow_1.result.customerName}}
Credit score: {{execute_workflow_1.result.creditScore}}
Approved: {{execute_workflow_1.result.approved}}

Design Patterns

Microservices Pattern

Break your automation into small, focused workflows:

Workflow	Responsibility
Email Parser	Extract data from emails
Sentiment Analyzer	Determine sentiment of text
CRM Updater	Handle all CRM operations
Notifier	Send notifications across channels

Main workflows compose these workflows as needed.

Facade Pattern

Create a simplified workflow that orchestrates complex operations: Customer Onboarding Workflow (called by main workflow):

├── Create CRM record
├── Set up billing account
├── Send welcome email
├── Add to onboarding sequence
├── Notify account manager
└── Return summary

Callers don’t need to know these details.

Chain of Responsibility

Pass data through a series of processing workflows:

├── Execute Workflow (Validator) → validates input
├── Execute Workflow (Enricher) → adds data
├── Execute Workflow (Scorer) → calculates score
├── Execute Workflow (Router) → determines destination

Execution Behaviour

Execute Workflow always waits for the called workflow and returns its output — it is not a fire-and-forget trigger. How the target runs depends on the target application’s execution mode: a single-instance application reuses its live execution (deploy it first), while a multi-instance application starts a fresh run.

Recursion is allowed — a workflow may call itself or another entry point of the same application — but you own loop termination. Gate recursive calls behind a Condition.

Error Handling

When a called workflow fails, the Execute Workflow node captures the error:

├── Execute Workflow (risky operation)
├── Condition (status == "completed")
│   ├── Met: Continue normal flow
│   └── Unmet: Integration Action (alert team)

Check {{execute_workflow_1.status}} to handle failures gracefully.

Tips

Name workflows descriptively - “Invoice Processor v2” is better than “Workflow 1”. This makes the Execute Workflow node’s purpose clear in the workflow.

Version your workflows by creating copies before major changes. This prevents breaking dependent workflows.

Avoid circular dependencies where Workflow A calls Workflow B which calls Workflow A. This will cause infinite loops and eventual timeout.

Settings

string

default:"Execute Workflow"

Display name shown on the canvas.

string

default:"execute_workflow_1"

Unique identifier for referencing outputs.

string

required

The application to run. Select from a dropdown of applications in your workspace.

string

required

The entry node in the target application — a Start node that declares the input arguments callers must pass.

array

One row per declared argument: the argument name and the value to pass. Values can use {{...}} expressions from the current execution.

number

Override how long to wait for the called workflow to finish.

Outputs

object

The called workflow’s final outputs, keyed by node key — its return value.

boolean

Whether the called workflow completed successfully.

string

Execution status of the called run.

string

Unique identifier for the run of the called workflow.

number

How long the called workflow took to run (in milliseconds).

string

Error details when the call fails.

LLM

For simple AI tasks, an LLM node may be sufficient without a full workflow.

Execute Code

For data processing, code might be simpler than an workflow.

Overview

Triggers

Actions

Logic

Communication

Execute Workflow Node

When to Use

Example: Lead Qualification Pipeline

Example: Document Processing Hub

Example: Approval Workflow

Passing Data

Input Arguments

Receiving Results

Design Patterns

Microservices Pattern

Facade Pattern

Chain of Responsibility

Execution Behaviour

Error Handling

Tips

Settings

Outputs

LLM

Execute Code

​When to Use

​Example: Lead Qualification Pipeline

​Example: Document Processing Hub

​Example: Approval Workflow

​Passing Data

​Input Arguments

​Receiving Results

​Design Patterns

​Microservices Pattern

​Facade Pattern

​Chain of Responsibility

​Execution Behaviour

​Error Handling

​Tips

​Settings

​Outputs

​Related Nodes

LLM

Execute Code

When to Use

Example: Lead Qualification Pipeline

Example: Document Processing Hub

Example: Approval Workflow

Passing Data

Input Arguments

Receiving Results

Design Patterns

Microservices Pattern

Facade Pattern

Chain of Responsibility

Execution Behaviour

Error Handling

Tips

Settings

Outputs

Related Nodes