Workflows

Workflows allow you to compose integration flows from pre-defined actions (HubSpot, Jira, Google Workspace, and others), and the orchestration is then triggered by agents or directly by users. This section is currently in beta mode.

Where to find them

Open Build → Workflows. The Workflows tab lists the workflows you can access, with search and pagination. Create Workflow and row actions depend on your permissions.

Column	Meaning
Name	Opens the workflow detail.
Status	Active or inactive; save the active state before relying on a trigger.
Trigger	The workflow's configured entry point. A Schedule node can be set to On Demand without a recurring schedule.
Last run	When the most recent run was created, shown relative to now, or Never. This does not establish that it succeeded.
Created by	The workflow creator.
Access	The workflow's access setting.

The Runs tab lists accessible executions across workflows. To see only one workflow, search its name or open its detail and select Executions.

Creating a new workflow

1. Select Create Workflow. Use Rename Workflow in the action bar to set its name and description.
2. Open the + catalog and add a trigger. For a manually started example, choose Schedule, double-click the node, and keep Schedule Type → On Demand.
3. Reopen + and select actions from Tools, Agents, or Operators. Tools require suitable connections; an Agent node requires an accessible agent.
4. Drag nodes apart, then connect the source handle to the next node's input. Double-click a node to configure its required inputs and use expressions to map available outputs.
5. Switch to Active and select Save Workflow when the workflow is ready to run. Changes in the editor must be saved before callers use them.
6. Test with synthetic data and inspect its execution before sharing or attaching it to an agent.

Node Catalog

The workflow builder groups available nodes into four catalog tabs:

• Triggers: entry points that start a workflow, such as Webhook, Schedule, Recording transcribed, or Task created.
• Tools: connection-backed functions from enabled connections and their tool functions.
• Agents: assistant nodes that send input to a selected agent and return the assistant result.
• Operators: system flow-control nodes that shape how data moves through the workflow.

Organization settings affect what appears in the catalog. For example, Webhook nodes require the Webhooks organization feature, Recording transcribed requires Recordings, and Tools depend on connection availability and governance. Webhook choices are limited by ownership unless the user has Webhooks.ManageAll. Saving a binding also checks that the editor and workflow creator may use that webhook within the same organization; an administrator editing a workflow does not lend their access to its creator.

System Operators

Operators are built-in workflow nodes. They are not external connections and do not require credentials. Use them when the workflow needs to repeat work, collect results, or route around failures.

Operator	Output fields	What it does
Iterator	item, index	Splits a collection or configured values into separate branches. Each item gets its own run path, and downstream nodes run once per item.
Aggregator	result, count	Collects values produced inside iterator branches and returns one combined result after the repeated work is complete.

Iterator

Use Iterator when one workflow step returns or receives multiple items and the next steps should run once per item.

Inside each iteration:

• item contains the current item value,
• index contains the zero-based position of the item,
• downstream steps are isolated for that iteration,
• edge conditions are evaluated per item before the next node is queued.

Typical use cases:

• process every row returned by a data lookup,
• create one ticket per matching record,
• send one notification per item,
• call an agent once for each item in a list.

Aggregator

Use Aggregator after an Iterator when the workflow needs to collect per-item results back into one output. Aggregator settings define which values are collected from upstream node output.

When all iteration branches are complete, the Aggregator emits:

• result: the aggregated collection,
• count: the number of aggregated items.

Use Aggregator when later workflow steps need a combined summary, a single payload, or one final assistant/tool call after all items have been processed.

Error Handler

Use Error handler when a workflow needs a dedicated path for failed node execution. The released backend supports error-edge routing into an Error handler node so the workflow can record, skip, or commit a controlled failure outcome instead of stopping without context.

Use it when:

• one branch should continue even if an upstream tool call fails,
• the workflow should emit a handled error status instead of a silent stop,
• operators want a reviewable fallback path for risky external actions.

Even with Error handler available, still combine it with:

• clear edge conditions,
• tool approval and confirmation settings,
• workflow run history,
• node runs, Tool Executions, and Audit Log diagnostics.

Edge settings (Conditions)

You can open Edge settings on the lines between nodes. In this section, you set conditions that determine when the workflow should take a specific branch.

Configurable items:

• Label for naming the branch.
• One or more rules in the Condition section.
• Operator (e.g., Text equals) and comparison value.
• Add rule to add another condition.

Typical actions and examples

• HubSpot: GetDealById, GetContactById – reading a deal/contact before passing it to other systems.
• Jira: GetUserAsync, AssignTicketAsync, CreateTicketAsync – enriching a contact or creating a ticket.
• Google Calendar: CreateEventAsync – creating a meeting after successful data enrichment.
• Google Drive: ListFilesAsync, ReadFileAsync – working with documents.
• LLM / Webhook: calling a model or webhook to supplement logic, validation, or notification. You can find the procedure for creating a webhook on the Webhooks page.

Best practices

• Input validation: verify IDs, emails, and required parameters before connecting additional nodes.
• API errors: account for errors from integration services (timeout, rate limit) and add a fallback.
• Naming: name nodes according to their function (e.g., “Find HubSpot Contact”, “Create Jira Ticket”).
• Security: work only with access rights that are necessary for the given workflow; keep sensitive values in a vault/secrets.

Text and attachment expressions

In a node input, type / to open suggestions. Functions includes base64() and htmlAttachment() with usage hints. Insert a function and provide literal text or a value selected from an upstream node. Replace NODE_ID below with that node's actual ID; the nested braces are part of the syntax.

Expression	Result
{{func.base64(Dobrý den)}}	RG9icsO9IGRlbg== — UTF-8 text encoded in Base64.
{{func.htmlAttachment(<html><body>Demo</body></html>)}}	A JSON string representing an array containing one HTML attachment.
{{func.htmlAttachment({{[NODE_ID].result}})}}	The same attachment structure, using the upstream result text. Use the output field actually exposed by that node.

For the literal HTML example, the returned JSON is:

[
  {
    "fileName": "report.html",
    "mimeType": "text/html; charset=utf-8",
    "fileBase64": "PGh0bWw+PGJvZHk+RGVtbzwvYm9keT48L2h0bWw+"
  }
]

Map the whole htmlAttachment expression to an email function's attachmentsJson parameter when that function accepts this structure. It prepares the attachment data; it does not send email or publish a conversation artifact. base64 does not create an attachment object by itself, and its output is not encryption.

If an agent response contains an HTML document surrounded by commentary, htmlAttachment selects the first document from its optional doctype and <html> start through the first closing </html> tag. With no HTML start it encodes the entire input; with no closing tag it takes the remaining text from the HTML start. It does not validate or sanitize HTML. An empty argument returns an empty string.

Map Drive outputs into the next step

Verified for the dev releases of September 18, 2026. Production availability has not been confirmed. This is a conceptual example using output field names, not expression syntax or exact picker labels.

1. List files with Google Drive or OneDrive.
2. Check Files. If it is empty, finish with a no-results outcome instead of trying to read a file.
3. Pass the populated Files array to an Iterator. For each item, verify that it identifies the intended file before reading it.
4. Read the selected file. Google Drive's ReadFileAsync takes its Name, not its Id, and exports CSV. OneDrive supports a name/path or a full Microsoft file URL through the corresponding reader.
5. Check the read result before processing it: pass usable Content to the next text-processing step. Route missing or empty content to a no-content outcome. If OneDrive returns only ContentBase64, use a binary-capable step or handle the file separately; do not treat it as text.

Existing text outputs remain available. Workflows that parse them can adopt structured fields incrementally; no mandatory migration is required. Automatic output-schema refresh for existing nodes has not been verified. Inspect the available fields and a test run's outputs before changing mappings.

Editing and management

• In the list of workflows, search for the name/keyword and open the item.
• Use the access selector in the builder action bar to review and save sharing. Own-team sharing and organization-wide sharing require different permissions.
• You can edit, save, and rerun the workflow – changes will take effect in new runs.
• Recommended: after significant changes, test the flow on non-production data (test deals/tickets/calendar).

Workflow Detail

Opening a workflow takes you to its detail page at /internal/workflows/[workflowId]. The detail page is where you review the workflow canvas, edit nodes, test changes, and inspect how the workflow is configured.

Use the detail page to:

• review the trigger and connected actions,
• inspect node inputs and outputs,
• update node parameters,
• adjust edge conditions,
• check access and sharing,
• run or rerun the workflow when the workflow is ready to test,
• save changes before users or agents rely on the updated version.

When diagnosing a workflow, start from the trigger, then follow each node in order. Check whether required inputs are present before looking at later nodes, because a missing ID, email, file, or token at the beginning often causes downstream errors.

Running and Testing

Run workflows with test data before sharing them broadly. This is especially important when a workflow writes to external systems such as Jira, HubSpot, Google Calendar, or email.

Recommended testing flow:

1. Use a non-production record or test account.
2. Run the workflow once with the smallest possible input.
3. Verify every external side effect in the target system.
4. Check tool executions and logs if a node fails.
5. Only then share the workflow with a team or connect it to an agent.

Inspect executions

1. Open Build → Workflows → Runs and search the workflow name. Refresh the list if a newly queued run is not visible yet.
2. Check Execution ID, Created At, and Status. A chat acknowledgement or Last run timestamp is not a completion check.
3. Expand the run row to inspect Node runs and output fields. Alternatively, open the workflow detail and select Executions.
4. Follow an agent conversation link when offered; for a connection action, inspect the relevant Tool Execution and the target system.

The History panel below is the editor's change history. It does not replace execution results.

Change history

In the right panel History, you can view previous changes to the workflow (added/moved nodes, initial state) and revert to earlier versions.

Sharing workflow

In the Access / Sharing section, you can set:

• Visibility (Private / Shared),
• Organization Access (e.g., Can Use),
• Team Access to add specific teams.

This determines who can use or manage the workflow within the organization.

Diagnostics

When a workflow does not behave as expected, check:

• Node configuration: required parameters, IDs, email addresses, calendar IDs, project keys, and field mappings.
• Edge conditions: whether a condition is too strict or points to the wrong branch.
• Connection access: whether the workflow has access to the connection and function it needs.
• External API result: whether the target service returned an error, rate limit, permission issue, or validation error.
• Tool Executions: whether the underlying tool call is pending, failed, or waiting for approval.
• Audit Log: whether a recent configuration or access change affected the workflow.

If a workflow changed recently, compare the current version with the History panel before editing again.

Common scenarios

• Sync HubSpot → Jira → Calendar: obtaining a deal and contact, finding a user in Jira, creating a ticket and meeting.
• Incident intake: creating a ticket, attaching files from Drive, and notifying via webhook/LLM.
• Onboarding: creating a user in internal systems, adding to groups, and scheduling an introductory meeting.

Sample workflows:

Task workflows

Use Task created to start a workflow when a new task is created in the selected workspace. Selecting a workspace's default agent does not automatically run its tasks; configure a workflow for automatic execution. Existing tasks are not started by saving the workflow, and Run is unavailable for this event trigger: test it by creating a new task in that workspace.

Before creating the test task, switch the workflow to Active in the builder's action bar and select Save Workflow. An inactive workflow does not receive task-created events. Use Task created as the workflow's only trigger and root node; do not combine it with a schedule or webhook trigger.

Node	Configuration	Result
Task created (Triggers)	Select the workspace.	Passes the newly created task to the next node.
Create task (Operators)	Select a workspace; provide a summary, optional prompt, and optional status.	Creates a task in that workspace.
Update task (Operators)	Select a workspace, map the task ID, and enable at least one field to change: summary, status, or prompt.	Updates that task; fields not selected for update keep their values.

Task nodes expose taskId, workspaceId, summary, taskStatus, prompt, and a JSON result. Use taskStatus for the business status (Todo, InProgress, Review, or Done); the separate status output describes node completion. An enabled empty prompt in Update task clears the prompt.

For example: Task created → Agent → Update task. Select the intake workspace, map the task prompt into the Agent node, and map the original taskId into Update task. Set the task to Review only after the agent step succeeds. Inspect the workflow run and resulting task before expanding the intake.

Editing the workflow requires the relevant workflow permissions. Task created requires task view access; Create task and Update task require task edit access and access to the selected workspace. Share the workflow and workspace deliberately, and avoid building a chain that repeatedly creates tasks in the same intake workspace.

Start a workflow from an agent

Enable Workflows under the agent's Configuration → System Tools, select the workflows it may start, and save with Submit. See configuration and access requirements and the tool reference.

When the user explicitly requests a run, the agent can call trigger_workflow with an assigned workflow ID and a string input. The input can be plain text or JSON serialized as a string. Only accessible, active, non-deleted assigned workflows are callable; Task created workflows require a task event and cannot be started this way. A workflow cannot start itself again from its own running chain.

Example user request:

Start Docs Workflow Demo once with this JSON input: {"period":"2026-10","mode":"synthetic"}. Tell me whether it was queued; I will check the result in Workflows.

A successful tool response confirms submission for background execution. It does not wait for completion or return the workflow result into this chat. Check Runs for the actual outcome; an inactive creator or missing creator execution permission can prevent processing even after submission.

The launch input is not automatically mapped into every downstream node. In particular, Schedule currently exposes completion status but no payload output. Check the selected trigger's outputs and explicit node mappings before relying on a user-supplied input; the on-demand example above demonstrates launching, not automatic forwarding of that JSON to its Agent node.