Heym Full Feature Set — Reference

A comprehensive overview of all Heym capabilities. Each section describes a feature or concept in a few sentences.

Getting Started

Introduction

Heym is an AI-native low-code automation platform with a visual workflow editor. You build automations by connecting nodes on a canvas—no coding required for most use cases. It supports visual workflows, AI-powered nodes (LLM, Agent Node, Qdrant RAG), an AI Assistant, integrations (HTTP, GitHub, Jira, Notion, WebSocket Send, Telegram, Slack, inbound IMAP Trigger email, outbound Send Email), scheduling with Cron, and Portal chat portals for end users.

Why Heym

Heym is built from the ground up around LLMs, agents, and intelligent automation—unlike trigger-action tools that added AI as a plugin. It ships a first-class LLM node and Agent Node with tool calling, Python tools, MCP connections, skills, multi-agent orchestration, and provider-native LLM batch execution with live status branches. Built-in Qdrant RAG, natural-language workflow building, Traces, and Evals make it purpose-built for AI workflows; self-hosting keeps your data on your infrastructure.

See also Agent Node, LLM, Qdrant RAG, and Agent Architecture.

Quick Start

Get your first workflow running in minutes: create a workflow from the Workflows tab, add an Input node, an LLM node, and an Output node, then connect them. Configure the LLM with a credential and set userMessage to $input.text; use Run or the AI Assistant to execute or generate workflows with natural language.

Pairs naturally with Input, LLM, Output, and Expression DSL.

Core Concepts

Workflows are directed graphs of nodes connected by edges; execution flows from trigger nodes (Input, Cron, Telegram Trigger, Discord Trigger, IMAP Trigger, Heym Trigger, WebSocket Trigger) through processing nodes to Output nodes. Each node has a type, data (configuration), and inputs/outputs; edges define data flow. Nodes reference upstream data via Expression DSL expressions such as $nodeLabel.field; independent nodes run in parallel automatically.

Running & Deployment

Heym provides run.sh for local development (database in Docker, FastAPI backend, Vite frontend) and deploy.sh for production with Docker Compose. Both use a .env file; key variables include SECRET_KEY, ENCRYPTION_KEY, DATABASE_URL, and ALLOW_REGISTER. Development runs on configurable frontend and backend ports; production serves the API under /api through the frontend container.

See also Security, Enterprise, and Settings.

Migrate to Heym

The AI Convert tool turns a workflow from another platform (n8n, Flowise, Dify, Langflow, sim.ai, Activepieces) or a plain-English description into a Heym workflow, streamed live onto a canvas and ready to download and import. It runs an AI safety check, then generates the DSL with input and rate limits in place. Open it at heym.run/convert.

See also Quick Start, Download & Import, and AI Assistant.

Nodes

Triggers

Input

The Input node is the entry point for workflows that receive data from the user or API caller. It supports single or multiple input fields and exposes request metadata (headers, query params). Access body fields via $nodeLabel.body.fieldKey, headers via $nodeLabel.headers, and query via $nodeLabel.query.

Pairs naturally with Condition, LLM, and Output. For payload references and field access, see Expression DSL and Webhooks.

Cron

The Cron node triggers a workflow on a schedule using a standard five-field cron expression. No user input is required—the workflow runs automatically at the specified times (e.g. hourly, daily, every 15 minutes). Output is a trigger event with no payload.

See also Triggers, Wait, and Execution History for scheduled and delayed runs.

IMAP Trigger

The IMAP Trigger node polls an inbox on a configurable minute interval and starts a workflow for each newly detected email. It outputs parsed headers, sender and recipient lists, plain-text and HTML bodies, attachment metadata, and a trigger timestamp. Use it for support inbox triage, mailbox-to-Slack routing, or email-driven approval flows with Human-in-the-Loop.

Pairs with Send Email, LLM, and Slack for inbound triage and response workflows.

Heym Trigger

The Heym Trigger node starts a workflow when Heym itself publishes a platform event: heym.started, workflow.created, workflow.updated, or workflow.deleted. Delivery is batched - every event published inside one five-second dispatch window arrives in a single run as $nodeLabel.events, always an array. Each event is claimed through a unique database constraint, so it fires exactly once per subscribing node no matter how many workers, containers, or machines are running. Use it for workflow change audit trails, deploy announcements, and instance health digests.

Pairs with the Heym node to look up the changed workflow, and with Loop to act once per event.

Heym

The Heym node reads Heym's own data through three operations: listWorkflows returns every workflow the owner can reach with node counts and timestamps, getWorkflow returns one workflow's node and edge structure, and getExecutionHistory returns execution-history entries newest-first with optional status, time-window, and limit filters, alongside totals grouped by status. Results are scoped to the owner of the workflow the node lives in, so a run started by cron, a portal, or an event returns the same data as a manual run. getWorkflow returns the full node configuration, which is what makes auditing a workflow for hardcoded keys or tokens possible; it exposes nothing the workflow owner could not already open in the editor. No credential is required.

WebSocket Trigger

The WebSocket Trigger node opens an outbound client connection to an external WebSocket server and starts the workflow on onMessage, onConnected, or onClosed. It exposes parsed message payloads, reconnect state, close metadata, and the socket URL for downstream expressions.

Pairs with WebSocket Send, HTTP, and SSE Streaming for realtime integrations.

Telegram Trigger

The Telegram Trigger node receives bot webhook updates and starts the workflow immediately. It exposes the full update payload, the primary message object, callback queries, sanitized headers, and a trigger timestamp. Use it for chatbots, AI assistants in Telegram, and button-driven flows.

Pairs with Telegram, Agent Node, and Webhooks for bot-driven workflows.

Slack Trigger

The Slack Trigger node receives Slack Events API webhooks and starts a workflow automatically after verifying the request signature. It exposes the event payload and sanitized headers for downstream routing, LLM-based classification, and reply flows.

Pairs with Slack, Agent Node, and Third-Party Integrations.

Discord Trigger

The Discord Trigger node receives Discord Interactions API webhooks, verifies Ed25519 signatures with the selected discord_trigger credential, and starts the workflow. It exposes the full interaction payload, command data, sanitized headers, and trigger metadata for downstream routing or replies.

Pairs with Output, Discord, Agent Node, and Third-Party Integrations.

RabbitMQ

The RabbitMQ node sends or receives messages from RabbitMQ queues and exchanges. Use it for message-driven workflows and event processing. Send mode publishes a message with optional delay; receive mode acts as a trigger so the workflow starts when a message arrives. Output includes status, message_id, and body.

Pairs with Condition, Error Handler, and Parallel Execution for event-driven processing.

Error Handler

The Error Handler node runs automatically when any node in the workflow fails. No incoming edges are needed; it is triggered by the engine. Output includes error message, failed node label, node type, and timestamp. Use it to send notifications through Slack, Telegram, or Send Email, log errors, or return custom error responses.

As an alternative to handling errors on the canvas, a workflow can also delegate failures to a separate workflow — see Error Workflow. If the canvas already contains an Error Handler node, the error workflow is not called (the local handler takes precedence).

Common notification targets are Slack, Telegram, and Send Email; run details are easier to inspect in Execution History.

AI

Agent Node

The AI Agent node is an LLM node with tool calling. It can run Python tools, call connected canvas nodes as tools, connect to MCP servers, use skills (instruction files and optional Python scripts), act as an orchestrator that delegates to other agent nodes, and call other workflows as tools. Output is available as $nodeLabel.text. An optional Extra Body toggle attaches a JSON object of provider-specific request parameters to every request in the tool-calling loop; it is off by default.

Canvas node tools let an agent call configured workflow nodes directly from the canvas. Connect a supported node to the agent's tools handle, then mark specific fields as agent-provided with the bot icon. Those fields become tool parameters at runtime, while credentials and unmarked fields stay fixed in the node configuration.

The Skills section now includes AI Build for creating new skills, an inline AI edit action for existing skills, per-skill ZIP download, and an optional Enable Drive files switch for skills that need to read Heym Drive files at runtime. The Skill Builder modal streams a chat conversation on the left, accepts drag-and-drop files with each fine-tune comment, shows a live read-only preview of generated SKILL.md and .py files on the right, can download that preview as a ZIP, and saves uploaded fine-tune files back as bundled skill assets through the same ZIP ingestion flow used by manual uploads.

With Agent Persistent Memory enabled, each agent node keeps its own knowledge graph: facts are loaded into the system prompt when non-empty, and successful runs trigger a background merge of new entities and relationships. Sub-agents use separate graphs. You can share an agent’s graph with other agents (same or other workflows) with read-only or read/write access from the graph dialog. The canvas brain control opens the graph editor.

Agent nodes can also enter Human-in-the-Loop mode. In this mode the agent gets a request_human_review tool and can pause at specific approval-required steps, create a one-time public review link, expose a review canvas branch for notification flows, and wait until a reviewer accepts, edits, or refuses the Markdown review text. The node's HITL field acts as approval guidelines for when to ask, while the reviewer-facing summary is generated from each review request. For MCP tools, Heym uses the model to interpret those written instructions into always, once, or never, so freeform approval language maps to a concrete runtime policy. The run is marked pending and resumes from the stored execution snapshot after the decision arrives, and the same agent run can pause more than once if later steps also require review.

Agent nodes automatically compress their accumulated message history when it approaches 80% of the model's context window. The system prompt, first user message, and most recent user message are always preserved; everything in between is summarized using the same model and credential. Compression events are visible in the Debug panel, Execution History, and the Traces tab.

Codex

The Codex node runs the OpenAI Codex CLI inside an isolated Heym workspace. It accepts a Codex credential (sign in with ChatGPT to use your subscription without per-token API costs, or paste an access token), a GitHub credential, repository URL, base branch, task prompt, publish mode (diff_only or draft_pr), branch name, and timeout. The runner clones the repository locally, passes the ChatGPT token bundle or CODEX_ACCESS_TOKEN only to the Codex process, and returns a structured summary, validation notes, changed files, diff, usage metadata, and an optional draft PR URL.

When Codex returns needs_input, the workflow pauses and exposes the question branch. Connect that branch to Slack, email, or another notification node; the public follow-up link resumes the saved execution snapshot after the answer is submitted. The Codex node can also be attached to an AI Agent as a tool, letting the agent delegate coding tasks; as a tool, a needs_input result is returned inline to the agent instead of pausing the workflow.

See also GitHub, Credentials, Credentials Sharing, and Node Types.

OpenCode Go

The OpenCode Go node runs the OpenCode CLI (Go) against a GitHub repository. Isolation follows the Codex pattern: locally it runs as a host subprocess, while Docker deployments run it inside a hardened sibling container that shares the workspace volume. It accepts an OpenCode Go credential (a gateway API key with an optional base URL), a GitHub credential, repository URL, base branch, task prompt, publish mode, branch name, timeout, and an opencode-go/<model> model chosen from a live, searchable model list (with a built-in fallback). Heym performs all git/GitHub operations on the host and never places the GitHub token inside the sandbox; OpenCode only edits files on disk. The node returns a structured summary, validation notes, changed files, diff, and an optional pull request URL. It can be attached to an AI Agent as a tool.

See also Codex, GitHub, Credentials, Credentials Sharing, and Node Types.

LLM

The LLM node processes text with a language model or generates images. It supports text generation, vision (image input), image generation, structured JSON output, and provider-native Batch API execution for supported OpenAI and OpenAI-compatible endpoints. Configure credential, model, system and user messages, temperature, and max tokens; use Expression DSL in prompts. In batch mode the userMessage must resolve to an array, the node emits a batchStatus branch with progress updates, and the final output includes per-item batch results. An optional Extra Body toggle attaches a JSON object of provider-specific request parameters (for example {"thinking": {"type": "disabled"}}) to each API call; it is off by default. Optional Guardrails block unsafe content before the call.

Pairs naturally with Qdrant RAG, Agent Node, Guardrails, and Expression Evaluation Dialog.

RAG / Vector Store

The RAG / Vector Store node inserts documents into or searches a vector store for retrieval-augmented generation. A Database dropdown selects the backend — Qdrant (external server) or Postgres (pgvector) (Heym's own database, no external service), defaulting to Qdrant. Choose a vector store from the Vectorstores tab and set the operation to insert or search. Search supports metadata filters and optional Cohere reranking, and returns an array of results with text, score, metadata, reranked flag, and count for use in LLM or Agent Node flows.

Common downstream nodes are LLM and Agent Node; vector store setup lives in Vectorstores.

MCP Call Node

The MCP Call node calls a specific MCP tool directly, without an LLM deciding which tool to invoke. Use it when you know exactly which tool to run at design time — for deterministic, single-step MCP tool execution in a workflow. Configure a connection (SSE, Streamable HTTP, or stdio; same fields as the Agent Node MCP connection), click Fetch Tools to populate a dropdown, select a tool, and fill in argument fields that are auto-rendered from the tool's input schema. Each argument accepts a static value or a DSL expression such as $userInput.body.text. The result is available as $nodeLabel.result (JSON object if parseable, otherwise string). The MCP Call node cannot be connected to an Agent Node as a canvas tool.

See also Agent Node, MCP, and Expression DSL.

Logic

Condition

The Condition node branches the workflow based on an if/else expression. It has two output handles: one for when the condition is truthy and one for falsy. Use comparison and logical operators from the Expression DSL in the condition expression; the node passes through input to the chosen branch.

See also Switch, Throw Error, and Expression DSL.

Switch

The Switch node routes execution to different paths by matching a value against cases. Configure an expression to evaluate and a list of case values; each case gets a source handle and a default handle is used for non-matching values. Input is passed through to the matched branch.

Use Condition for binary branching and Merge to rejoin routed paths; matching rules are covered in Expression DSL.

Merge

The Merge node waits for multiple parallel inputs and combines them into a single output. Set the number of inputs to wait for; the node produces a merged object once all branches have completed. Use it to join results from parallel branches before continuing; do not use it when parallel branches end in separate Output nodes.

See also Parallel Execution, Loop, and Output when recombining branches.

Loop

The Loop node iterates over an array, executing downstream nodes for each item. It requires a back-connection from the last node in the iteration body to advance. Inside the loop body use item, index, total, isFirst, and isLast; the loop has separate outputs for the iteration path and the done path.

Pairs with Variable, Merge, and Expression DSL for iterative workflows.

Data

Set

The Set node transforms and maps input data to custom output. Define key-value mappings where each value is an Expression DSL expression. Use it for uppercase, substring, concatenation, random numbers, and similar transformations. Access output by key (e.g. $setNode.keyName). When connected to an agent as a canvas node tool, mapping values can be marked as agent-provided so the agent fills them at runtime. For calling other workflows use the Execute node instead.

See also Variable, Execute, and Expression DSL.

Converter

The Converter node converts data between formats without writing code. Text conversions are csvToJson (CSV text into an array of row objects, or arrays when there is no header), jsonToCsv (an array of objects/rows into CSV text), xmlToJson (XML text into an object), and jsonToXml (an object into XML text). Configure the conversion direction and source expression; CSV conversions additionally use a delimiter and header handling, and jsonToCsv can pin an explicit column order. Quoting, embedded delimiters, and embedded newlines follow RFC 4180. XML attributes use @ prefixes, text mixed with attributes uses #text, repeated elements become arrays, and XML entity expansion is disabled. The same node also works on stored files. imageToText and pdfToText run Tesseract OCR, reading a file from Heym Drive ($Upload.file.id from a File upload trigger, a Drive node result, or an agent's generated file), picking the language automatically from the detected script or using codes you name such as tur or eng+tur, and normalizing the text to UTF-8 by default with optional NFC normalization and narrower charsets like cp1254. fileConvert rewrites a stored file in another format, documents through pandoc and images through Pillow, and saves the result as a new Drive file without touching the original. The result is available as $converterNode.result, with .language, .encoding, .page_count, .pages, and .file alongside it for OCR runs, and .id, .filename, and .download_url for fileConvert.

See also Set, DataTable, and Expression DSL.

Variable

The Variable node sets or updates a workflow-local variable ($vars.variableName) or a persistent global variable ($global.variableName). Use it for counters, accumulated lists, and shared state. Configure variable name, value expression, type coercion, and whether to store in the global store. Array variables support $array() and .add().

Pairs with Set, Loop, and Global Variables.

Execute

The Execute node calls another workflow (sub-workflow) and passes input to it. Specify the target workflow by ID and provide input via a single expression or key-value mappings. Output includes workflow_id, status, and outputs; use it for reusable logic, not for data transformation (use Set for that).

See also Canvas Features for Extract to Sub-Workflow, Workflow Structure, and Output.

Integrations

HTTP

The HTTP node makes HTTP requests using cURL-style configuration. It can be a workflow starting point (no incoming edge) or receive input from upstream nodes. Response is available as status, headers, and body (parsed JSON when applicable). Use Credentials for Bearer or custom header auth.

Pairs with Webhooks, Credentials, and Third-Party Integrations.

WebSocket Send

The WebSocket Send node opens an outbound client connection, sends one text/JSON/binary message, and closes it. Use it to publish workflow output to realtime systems without creating a Heym-hosted socket endpoint.

The Telegram node sends a bot message to a chat, group, or channel. Configure a Telegram credential, set chatId, and compose the outgoing message with Expression DSL expressions. It pairs naturally with Telegram Trigger for conversational workflows and with Error Handler for operator alerts.

See also Third-Party Integrations and Credentials for setup and credential patterns.

Slack

The Slack node sends a message to a Slack channel via an Incoming Webhook. Configure a Slack credential and a message expression. Use it for notifications, alerts, and error reporting; output passes through input.

Pairs with Slack Trigger, Error Handler, and Third-Party Integrations.

Discord

The Discord node sends a message to a Discord channel via an Incoming Webhook. Configure a Discord credential, compose the outgoing message with Expression DSL, and optionally set webhook username or avatar overrides.

Pairs with Discord Trigger, Output, Error Handler, and Third-Party Integrations.

Send Email

The Send Email node sends emails via SMTP. Configure an SMTP credential and Expression DSL expressions for recipient(s), subject, and body. Use it for notifications, alerts, and transactional emails. Output includes status, to, and subject.

The IMAP Trigger complements Send Email by handling inbound mail. Together they let a workflow read incoming email from a shared inbox, summarize or classify it with AI nodes, and send a follow-up or escalation message. The Telegram Trigger and Telegram node provide the same inbound/outbound pattern for bot-driven chat workflows.

For two-way notification flows, it also pairs well with LLM, Agent Node, and Third-Party Integrations.

Redis

The Redis node performs Redis operations: set, get, hasKey, and deleteKey. Use it for caching, rate limiting, and key-value storage. Configure a credential, operation type, key expression, and for set operations value and optional TTL. Output varies by operation (value, success, exists, deleted).

Pairs with Wait, Variable, and Parallel Execution for caching, throttling, and coordination.

Grist

The Grist node reads, writes, and manages data in Grist spreadsheets. Operations include getRecord, getRecords, createRecord, updateRecord, deleteRecord, listTables, and listColumns. Provide document ID, table ID, and for create/update the record data using column IDs. Use it for CRUD, batch updates, and spreadsheet automation.

Google Sheets

The Google Sheets node reads, writes, and manages spreadsheet data via OAuth2. Use it to read reports, append workflow results, update trackers, and clear or inspect sheet tabs from within a workflow. Like BigQuery, it uses a Google-backed integration credential and fits well beside Grist when spreadsheet data is part of the flow.

Pairs with Grist, DataTable, and Third-Party Integrations.

BigQuery

The BigQuery node runs SQL queries and inserts rows into Google BigQuery datasets via OAuth2. It is useful for analytics workflows, reporting pipelines, and writing structured event data from workflow runs. It often pairs with Set for shaping rows and Google Sheets for lighter spreadsheet-oriented reporting.

Pairs with Set, LLM, Google Sheets, and Third-Party Integrations.

Google Drive

The Google Drive node lists, downloads, updates, and deletes Drive files and folders via OAuth2, and can copy a Drive file straight into Heym Drive with its syncToHeymDrive operation. Google Docs, Sheets, and Slides have no downloadable bytes, so the node exports them automatically — Docs to PDF, Sheets to XLSX, Slides to PPTX — with an override for the target format. Deletions move items to Drive trash unless "Delete permanently" is enabled, and the node refuses to delete a folder through the file operation or vice versa. Like Google Sheets, it uses a Google-backed OAuth2 credential; note that this one requests full Drive access, so review Credential Sharing before sharing it.

Pairs with Loop, Drive, LLM, and Third-Party Integrations.

GitHub

The GitHub node provides 40 native GitHub REST actions covering repositories, organizations and users, issues, pull requests, reviews, releases, Actions workflows, traffic insights, and repository files. Use it for issue triage, review automation, workflow dispatch and completion waits, release automation, and repo file updates without hand-building HTTP requests. It supports GitHub.com and optional GitHub Enterprise base_url on the credential.

Pairs with Agent Node, HTTP, Set, and Third-Party Integrations.

Jira

The Jira node connects workflows to Jira Cloud or Jira Data Center / Server REST APIs for project, issue, comment, attachment, user, notification, and transition automation. It can list projects, search issues with JQL, create or update issues, inspect changelogs, notify stakeholders, manage comments and attachments, fetch or manage users, list available transitions, and move issues through a transition ID. Use a Jira credential with Atlassian email, API token, site base URL, and deployment mode.

Pairs with LLM, Agent Node, Slack, and Third-Party Integrations for support intake, bug triage, and release workflows.

Linear

The Linear node connects workflows to Linear's GraphQL API for workspace and issue automation. It can list teams, projects, issues, workflow states, team members, and comments; create, update, delete, and link issues; and create, update, resolve, unresolve, or delete comments. Use a Linear personal API key or OAuth2 credential, then discover team, project, state, and assignee UUIDs from list operations before creating or updating issues.

Pairs with LLM, Agent Node, Slack, and Third-Party Integrations for intake, triage, and engineering backlog workflows.

Supabase

The Supabase node reads and mutates tables exposed through Supabase PostgREST. It works well for product backends, user/profile data, workflow state, and CRUD-style automations that want database access without custom HTTP request wiring.

Pairs with Set, DataTable, HTTP, and Third-Party Integrations.

ClickHouse

The ClickHouse node runs CRUD, count, and raw SQL operations against an external ClickHouse database over its HTTP interface. It suits analytics pipelines, event logging, and reporting workflows: insert events as they happen, then aggregate or count them with query/count. It mirrors the DataTable operation set (find, getAll, count, getById, insert, update, remove, upsert) plus a raw SQL escape hatch, with update/remove running as ClickHouse mutations.

Pairs with Set, Cron for scheduled reports, and Third-Party Integrations.

Notion

The Notion node manages Notion databases, data sources, pages, and blocks through the current Notion API (2026-03-11). It supports search, page CRUD, database and data source operations, block children, append/update/delete blocks, and trash/restore. Use an internal integration token or a Notion public integration OAuth credential. The editor can search and cursor-paginate accessible data sources and parent pages. Shared credentials work the same as owned credentials for workflow execution.

For custom REST calls, $credentials.YourNotionCredential resolves to the same bearer token. Pairs with Set, HTTP, LLM, and Third-Party Integrations.

Sentry

The Sentry node automates Sentry organizations, projects, teams, issues, events, and releases through the Sentry REST API. Use it for alert triage, issue status updates, release automation, event lookup, and project/team setup or cleanup. It supports Sentry SaaS and self-hosted Sentry via an optional credential base URL.

Pairs with Error Handler, Slack, Linear, and Third-Party Integrations for incident and release workflows.

DataTable

The DataTable node reads, writes, and manages data in Heym DataTables (first-party structured storage). Operations include find, getAll, getById, insert, update, remove, and upsert. No external credentials required. Tables are managed from the DataTable dashboard tab and accessed directly by the workflow owner.

Pairs with Set, Variable, and the DataTable tab for first-party structured storage.

Drive

The Drive node manages files generated by skills directly from within a workflow. Operations include delete, setPassword, setTtl, setMaxDownloads, shareWithMyTeams, and unshareWithMyTeams for read-only team access management; format conversion lives in the Converter node instead. Reference the file with $agentLabel._generated_files[0].id; outputs include status, file_id, updated download_url for link constraints, and shared_team_count for team sharing. This is especially useful with Agent Node workflows that use File Generation and the Drive reference model.

Common companions are Agent Node, File Generation, and Drive.

Amazon S3

The Amazon S3 node runs object storage operations on Amazon S3 using an s3 credential (access key, secret key, region, optional session token). Operations include putObject, getObject, deleteObject, listObjects, copyObject, createBucket, deleteBucket, createFolder, deleteFolder, getAllFolder, and listBuckets. Text upload and text or base64 download are supported, with bucket and key fields accepting Expression DSL. Use it to store workflow outputs, archive files, and read objects back into a flow.

Pairs with Set, HTTP, Credentials, and Third-Party Integrations.

Automation

Crawler

The Crawler node scrapes web pages using FlareSolverr with optional HTML extraction via CSS selectors. Configure a FlareSolverr credential, URL expression, wait time, and optional selectors for extraction. Output is the raw HTML or extracted content. Use it for web scraping and content extraction.

Pairs with HTTP, Playwright, and LLM for scrape-and-analyze flows.

Playwright

The Playwright node automates browser interactions with configurable steps (navigate, click, type, screenshot, extract, aiStep) or Run Code mode for custom Playwright Python (sandboxed; off by default via HEYM_PLAYWRIGHT_CUSTOM_CODE_ENABLED). It supports headless mode, an optional setting that reduces common Playwright automation signals, timeouts, optional network capture (responses, cookies, localStorage, sessionStorage), cookie/storageState auth bootstrap from Global Variables expressions such as $global.authState, fallback login steps when auth restore fails, and an AI step with Auto Heal when selectors fail. Use it for web scraping, form filling, and browser-based workflows.

See also Crawler, HTTP, and Execution History for browser automation and debugging.

Utilities

Output

The Output node is the workflow endpoint that returns the response to the caller. Set the message expression to reference the previous node by label (never use $input from the Input node here). Optional async downstream allows nodes after the output to run in the background after the response is sent.

Common upstream sources are Input, LLM, and Execute; response shaping is easier to debug in Expression Evaluation Dialog.

JSON output mapper

The JSON output mapper node builds a plain JSON object from Set-style key-value mappings and returns it at the root of the workflow response. Use it when an API caller should receive a raw JSON body instead of the standard Output node wrapper.

Pairs with Set, Output, Workflow Structure, and Webhooks.

Chart Output

The Chart Output node is the terminal node of a Dashboard widget workflow. It turns the rows produced by upstream nodes into a standardized chart payload that the dashboard renders. Choose a chartType (bar, line, area, pie, table, numeric, gauge, scatter, proportion, bar gauge, or text), map labelField/valueField (or series for multi-series, or text for a markdown message), and place it last; it has no output edge.

Wait

The Wait node pauses workflow execution for a specified duration in milliseconds. Use it for rate limiting, delayed actions, or polling intervals. It passes through input unchanged.

Pairs with Cron, Redis, and Parallel Execution for pacing and polling.

Sticky Note

The Sticky Note node adds markdown notes to the canvas. It is not executed. Use it for documentation, instructions, or workflow notes alongside other Canvas Features. Double-click on the canvas to edit the note content.

Console Log

The Console Log node logs a value to the backend (server) console. Use it for debugging and inspection during development. The log message supports Expression DSL expressions; output passes through input.

Pairs with Execution History, Traces, and Expression Evaluation Dialog for debugging.

Disable Node

The Disable Node node permanently disables another node in the workflow by setting its active flag to false. Specify the target node by label. Use it for one-time operations such as stopping a Cron trigger after a condition is met.

See also Canvas Features, Edit History, and Cron for workflow control patterns.

Throw Error

The Throw Error node stops workflow execution immediately and returns an error response with a custom HTTP status code. Set the error message expression and status code (e.g. 400, 401, 403, 404, 429, 500). Use it for validation failures, unauthorized access, or other error conditions, especially when paired with Condition and Error Handler.

Pairs with Condition, Error Handler, and Security for explicit failure paths.

Reference

Node Types

Heym provides a variety of node types: triggers such as Input, Cron, Telegram Trigger, Discord Trigger, IMAP Trigger, Slack Trigger, Heym Trigger, RabbitMQ, and Error Handler; AI nodes such as LLM, Agent Node, Codex, OpenCode Go, Qdrant RAG, and MCP Call; logic nodes like Condition, Switch, Merge, and Loop; data nodes like Set, Converter, Variable, Execute, and Heym; integrations such as HTTP, GitHub, Jira, Linear, Notion, Sentry, Telegram, Slack, Discord, Send Email, Redis, Grist, Google Sheets, Google Drive, BigQuery, Supabase, ClickHouse, DataTable, and Drive; automation nodes like Crawler and Playwright; and utilities such as Wait, Output, JSON output mapper, Console Log, Throw Error, Disable Node, and Sticky Note. Use expressions like $input.text and $nodeLabel.field in node configuration.

Expression DSL

Heym uses a simple expression language to reference data from upstream nodes. Use $input for the Input node, $nodeLabel.field for any upstream node, $credentials.CredentialName for credentials, and $global.variableName for global variables. Built-in special variables include $now, $UUID, and workflow metadata: $workflowName, $workflowDescription, $workflowPath, $workflowUrl, and $executionId (the run's Execution History id — /workflows/{id}/{executionId} opens that run on the canvas; runtime-only, empty in the expression preview dialog). Support includes literals, arithmetic, comparisons, Loop context, nested fields, and string/array helpers (including $text.toJson() to parse a JSON string). When the full value is a single $expr, the backend preserves arrays, objects, booleans, and numbers as native types.

Global Variables

The Global Variable Store holds persistent, user-scoped key-value data that survives across workflow executions. Create variables from the Variables tab or from a Variable node with "Store in Global Variable Store" enabled. Access them with $global.variableName in expressions; they can be shared with other users or teams.

Pairs with Variable, Teams, and Credentials Sharing for shared workflow state.

Expression Evaluation Dialog

The Expression Evaluation Dialog is an expandable editor that appears when you click the expand button next to expression fields. It opens as a large centered modal, keeps autocomplete active, and refreshes backend preview output automatically after you pause typing. Object and array results can be browsed with the output path picker. The dialog accepts a full-line bare dot path (for example myNode.output.field) as if it were $myNode.output.field; see Expression DSL placement rules.

The Build with AI button in the toolbar lets you describe the expression you want in plain text. Select an LLM credential and model, type a description such as "Get the customer name from the API response", and click Generate. The backend sends the Expression DSL context and last-run node outputs to the model and returns a single expression string. The result is evaluated immediately so you can verify it before clicking Apply.

Pairs naturally with Expression DSL, Output, and JSON output mapper.

Workflow Structure

Workflows are stored as JSON with nodes and edges. The workflow object includes id, name, description, nodes, edges, and auth settings. Each node has id, type, position, and data (label and type-specific config). Edges connect source and target node IDs with optional handle IDs. Expression syntax in data fields follows the Expression DSL, and this same shape is used by Download & Import.

See also Node Types, Expression DSL, and Download & Import.

Canvas Features

The workflow editor provides Data Pin (pin a node's last output for testing downstream without re-running), Execution Logs (real-time node results and agent progress that complement Execution History), Enable/Disable (skip nodes during execution), and Extract to Sub-Workflow (move a selection into a new workflow and replace it with an Execute node). A running production execution can be opened from History or a Board card; the editor restores its current snapshot, attaches to SSE, and keeps the canvas animation and Debug logs live. Keyboard Shortcuts support copy, paste, run, and inline node search.

Keyboard Shortcuts

Heym provides shortcuts across the editor: Command Palette (Ctrl+K), Run (Ctrl+Enter), Save (Ctrl+S), Undo/Redo, and Escape to dismiss. On the canvas: select all, multi-select, copy/cut/paste, delete, toggle node enabled (D), toggle pinned data (P), and inline node search by typing. Shortcuts are documented in the in-app reference and work closely with Canvas Features such as Data Pin and node enable/disable.

AI Assistant

The AI Assistant is a chat panel opened from the Debug panel that lets you create or modify workflows with natural language. Select a credential and model, then describe what you want; the AI streams a response and any valid workflow JSON in a code block is automatically parsed and applied to the canvas. Voice input is supported on compatible browsers.

When the current workflow contains Agent Node skills, the assistant sends only each skill's SKILL.md into the workflow context. Attached .py files and binary skill assets are excluded before the request so large skill bundles do not overflow the model context window.

Pairs well with Chat with Docs, Agent Architecture, and Expression DSL.

Chat with Docs

Chat with Docs is a documentation-header assistant for product questions. It opens in a centered dialog, keeps credential and model selection visible at the top, injects the active docs page path as context, and clears message history when the dialog closes. It complements the broader AI Assistant and the lighter-weight Contextual Showcase.

See also AI Assistant, Contextual Showcase, and Node Types.

Workflow Organization

Workflows can be organized in folders and sub-folders in a tree structure. Folders have names and optional parent; workflows are assigned to folders. Workflows can be scheduled for deletion (moved to a trash area before permanent removal). The API supports create, update, delete, and moving workflows between folders, and the same organization model appears in the Workflows tab.

See also Quick Drawer, Download & Import, and Edit History.

Quick Drawer

The Quick Drawer is a fixed right-side fast-run panel for internal non-canvas pages. It lets you search workflows, pin favorites, select inputs, run immediately, and inspect progress or results without opening the editor. Pin order and the last selected workflow are stored in the browser.

Contextual Showcase

The Contextual Showcase is a compact in-app guide rail for authenticated main surfaces such as dashboard tabs, Evals, Docs, and the workflow editor. It stays closed by default, gives a short page summary first, offers a little extra detail on demand, and links to the full docs article when you want deeper guidance.

Pairs with Chat with Docs, Quick Drawer, and AI Assistant for in-app guidance flows.

Credentials

Credentials store API keys and secrets used by workflow nodes. Add them in the Credentials tab and reference them by name or ID in nodes such as LLM, Agent Node, HTTP, Telegram, Send Email, and Redis. They are encrypted at rest, can be shared with users or teams, and can also be referenced in Expression DSL via $credentials.Name.

Credentials can be shared with other users by email or with teams; all team members gain access when a credential is shared with a team. Shared credentials appear with an indicator in the Credentials tab. At runtime, the workflow owner's context merges owned, user-shared, and team-shared credentials. Use $credentials.CredentialName in expressions or set credentialId in node data.

See also Credentials, Teams, and Third-Party Integrations.

Teams

Teams let you share workflows, credentials, global variables, vector stores, and Drive files with a group of users at once. Create teams from the Teams tab and add members by email. Share resources with a team from the relevant share dialogs; all members then have access. The creator can edit and delete the team; deleting a team removes all team shares.

Pairs with Credentials Sharing, Global Variables, and Enterprise.

Parallel Execution

Heym runs nodes in parallel when they have no dependencies on each other. The executor builds a DAG and runs nodes in the same level concurrently with a thread pool; as soon as a node finishes, its downstream nodes are scheduled. Use the Merge node to combine parallel branches when needed. Multiple workflow runs execute concurrently; each run is isolated. SSE Streaming mode emits events as nodes complete.

See also Merge, Loop, and Execution History.

Agent Architecture

The Agent Node supports sub-agents (orchestrator calls other agent nodes via call_sub_agent), sub-workflows (agent calls other workflows via call_sub_workflow), skills (instruction content and Python tools from .zip or .md), and MCP client connections. The orchestrator tool executor routes sub-agent and sub-workflow calls; other tools go to Python, MCP, or skill executors. Max nesting depth for sub-agents and sub-workflows is 5. The tool-calling loop includes automatic context compression: before each iteration, token usage is estimated and if it exceeds 80% of the model's context window the middle messages are summarized using the same model, keeping the system prompt, first user message, and last user message intact.

Agent Persistent Memory

Optional per-Agent Node knowledge graph stored in Postgres: entities, types, properties, and directed relationships. When persistentMemoryEnabled is true, the graph is summarized into the system prompt on each run; after successful completions, an LLM extracts structured updates in the background. REST CRUD lives under /api/workflows/{workflow_id}/nodes/{canvas_node_id}/agent-memory/.... The editor opens from the pink brain control on the node.

See also Agent Node, Agent Architecture, and Traces.

Human-in-the-Loop

Human-in-the-loop lets an Agent Node request approval at specific checkpoints, create a public /review/{token} page, and wait for a non-logged-in reviewer to accept, edit, or refuse the Markdown review text. HITL-enabled agents also expose a review output handle so you can notify Slack, Send Email, or other channels while the run is pending. The node-level HITL text is used as approval guidelines, while the public-page summary is generated from the review request itself. Pending runs appear in Execution History immediately, can happen more than once in the same run, and resume from the exact stored workflow snapshot once each decision is submitted.

See also Agent Node, Portal, Execution History, and Send Email.

Webhooks

Workflows can be triggered via HTTP at POST /api/workflows/{workflow_id}/execute, or streamed incrementally from POST /api/workflows/{workflow_id}/execute/stream. The request body is passed as body to Input nodes; headers and query params are available in Expression DSL expressions. Configure per-workflow auth: anonymous, JWT, or custom header. Optional response caching, rate limiting, and the editor's Run with cURL dialog all live on the workflow and apply to both modes.

Execution Tokens

Execution tokens are scoped JWTs that grant access to a single workflow's execute and stream endpoints. When a workflow uses JWT authentication, tokens let external scripts, CI pipelines, and integrations call the workflow without sharing a user session. Each token carries a wid claim that pins it to one workflow, a jti used for instant revocation, and a configurable TTL (60 seconds to 10 years). Create, select, and revoke tokens directly from the Run with cURL dialog — the selected token is embedded in the generated command automatically.

See also Webhooks, Security, and SSE Streaming.

SSE Streaming

The cURL dialog can switch webhook execution into Server-Sent Events mode. This produces execution_started, node_start, node_complete, and execution_complete events in real time, adds --no-buffer to the generated cURL command, and lets you configure per-node start messages such as [START] LLM or custom text for external terminal consumers.

See also Webhooks, Execution History, and LLM.

Triggers

Workflows are started by trigger nodes (Input, Cron, Telegram Trigger, Discord Trigger, IMAP Trigger, Heym Trigger, RabbitMQ receive) or entry points: Webhook/API, MCP, Portal, Cron scheduler, Telegram webhook, Discord interaction webhook, IMAP trigger manager, RabbitMQ consumer, or Editor run. Each trigger has its own endpoint or background process; Cron runs every 60 seconds, Telegram Trigger nodes receive bot webhooks, Discord Trigger nodes receive signed interaction webhooks, and IMAP Trigger nodes run on their configured polling interval. Input nodes receive body, headers, and query from webhook requests.

See also Node Types, Webhooks, and Parallel Execution.

Execution History

Execution history records workflow runs: inputs, outputs, node results, status, and trigger source. Access it from the Editor toolbar, Docs view, Dashboard header, or Evals view. Per-workflow history shows runs for the open workflow; all-history view shows runs across workflows and chat. Currently running executions appear at the top of both dialogs with Open live and Cancel actions. Open live attaches the editor to the existing execution over SSE, restores completed nodes, pulses the current and pending nodes, and appends Debug logs without starting another run. Bring to Canvas loads a completed run's inputs and node outputs for re-run or debugging; the deep link /workflows/{workflowId}/{executionId} supports both live and completed executions. Human-in-the-Loop-paused runs are stored immediately as pending, including the public review URL and any notification nodes executed from the agent's review branch. If the server restarts mid-run, interrupted runs are recovered automatically: they are re-run from scratch with the same inputs and shown as completed (marked Recovered), controlled by a per-workflow Auto-recover runs toggle that can instead record them as skipped.

See also SSE Streaming, Human-in-the-Loop, and Traces.

Execution Highlights

After a live run — or after Bring to Canvas — a dismissible Execution Highlights popup appears in the top-right of the Canvas, listing what each node produced in execution order. It's a quick way to inspect per-node output without opening each node; close it with the ✕, and it reopens on the next run. Highlights are also shown on dashboard runs. See Execution History for details.

Edit History

Edit History tracks saved versions of a workflow (each Save creates a version). View the list, open a version to see a diff against the current workflow (nodes, edges, config), and Revert to restore a past version. Unlike Execution History, Edit History tracks structure changes, not runs.

Error Workflow

A workflow can designate another workflow to run when it fails. Configure it in the workflow-level Properties panel (shown when no node is selected) under On error, run workflow. When a top-level run ends with an unhandled failure, the selected error workflow runs and receives the failure context (failed workflow id and name, run id, error message, failed node label and type, and a timestamp). If the canvas already contains an Error Handler node, the local handler takes precedence and the error workflow is not called. The error workflow itself runs directly, so it never triggers its own error workflow. It is not triggered by manual canvas test runs — only by API and triggered runs.

Workflow Timeout

Each workflow can set a workflow timeout in seconds in the workflow-level Properties panel. 0 (the default) disables it. When set, a run that exceeds the limit is stopped at the next node boundary and recorded as a failed run with a "timed out" error. The timeout applies to manual, API, and triggered runs. Long Wait nodes are interrupted promptly rather than blocking for their full duration.

Time Saved

Each workflow can record an estimated time saved per run (in minutes), set in the workflow-level Properties panel. The Analytics tab aggregates this across the selected range as a total Time Saved stat (sum of each workflow's estimate × its successful runs). The Workflow Analysis report recommends setting an estimate when none is configured.

Settings

The Settings dialog (opened from the gear icon in the header) has four tabs: Profile (display name, User Rules), Security (change password), Voice (ElevenLabs TTS/STT), and Observability (read-only OpenTelemetry status). User Rules are custom instructions injected into every AI request, including the workflow builder and Chat, so you can set language, tone, coding style, or workflow conventions once. Password policy and MCP API key management are also available.

OpenTelemetry Tracing

Heym can emit OpenTelemetry traces for every workflow run and node execution: a root heym.workflow.execute span per run and a child heym.node.execute span per node, with model and token usage attached to LLM and agent nodes. Spans export over OTLP/HTTP to any compatible backend (Jaeger, Grafana Tempo, Honeycomb, Datadog), and W3C trace context propagates across inbound webhooks, outbound HTTP, and sub-workflows. Tracing is disabled by default and configured with HEYM_OTEL_* environment variables; the active status is shown in the Settings Observability tab.

See also Execution History, Traces, and Webhooks.

Download & Import

Export the current workflow as JSON from the Editor toolbar (Download button); the file includes nodes and edges. Import by dragging a JSON file onto the Workflows tab (creates a new workflow) or onto the canvas (replaces or merges). The JSON must include a nodes array; name and edges are optional. Use it for backup, sharing, or migrating between instances.

Portal

The Portal exposes workflows as public chat UIs at /chat/{slug}. Configure portal_enabled, slug, optional auth (portal users), streaming, and file upload per workflow. End users interact via a chat interface without logging into Heym; image outputs can be displayed in the chat. Portal workflows can also hand off to Human-in-the-Loop review pages when an Agent Node requires approval, while the agent's review branch sends notifications to other channels. Use it for internal tools, customer-facing chatbots, and AI-powered forms.

See also Human-in-the-Loop, Agent Node, and Drive.

File Generation

Skills can generate files such as PDF, DOCX, CSV, JSON, and images during execution by writing into the _OUTPUT_DIR workspace. Heym captures those files automatically, stores them, and exposes download metadata under _generated_files, which can then be managed with the Drive node or reviewed in the Drive tab.

See also Agent Node, Drive, and Drive node.

Drive

Drive is the shared storage and sharing layer for files generated by skills. It lets you browse files, create public or password-protected links, apply expiration and download limits, share files read-only with your teams, and manage those files programmatically with the Drive node or manually from the Drive tab.

See also Drive, File Generation, and Portal.

Security

Heym enforces a password policy (length, uppercase, lowercase, digit), stores access tokens in HttpOnly cookies, and rotates refresh tokens on use. Rate limiting applies to login, register, and Portal login. Credentials are encrypted at rest with AES-256 (Fernet). MCP API key is used for client auth; content safety is available via Guardrails on LLM and Agent Node nodes. Execution Tokens provide per-workflow scoped JWTs for external callers.

See also Execution Tokens, Guardrails, Portal, and Credentials.

Third-Party Integrations

Heym connects to external services through credentials stored in the Credentials tab (encrypted at rest). Supported types include OpenAI, Google, GitHub for the GitHub node and MCP integrations, Jira for the Jira node, Notion for the Notion node, Custom LLM, Cohere, RAG: Qdrant + OpenAI, RAG: Psql + OpenAI, Grist, SMTP for Send Email, RabbitMQ, Redis, Telegram, Slack, Bearer, Header, and FlareSolverr for Crawler. Each type documents required fields; credentials can be shared with users or teams and referenced by name in nodes or as $credentials.Name in expressions.

See also Credentials, Credentials Sharing, and Teams.

Guardrails

Guardrails block unsafe or unwanted user messages before they reach an LLM or Agent Node. Enable them per node and select categories to block (e.g. violence, hate speech, sexual content, self-harm, harassment, illegal activity). Set sensitivity (low, medium, high). When triggered, the node throws an error you can catch with an Error Handler. Detection uses the provider moderation API or LLM classification depending on credential type.

See also Security, LLM, Agent Node, and Error Handler.

Enterprise

Enterprise covers commercial licensing, professional support, and deployment services for teams running Heym in production. It includes workflow architecture help, onboarding, Kubernetes and scaling guidance, priority support, and custom development around advanced features such as Agent Node, Human-in-the-Loop, Parallel Execution, and Portal.

See also Running & Deployment, Security, and Teams.

Dashboard Tabs

Workflows

The Workflows tab is the default dashboard view. It shows your workflow list in a card grid or list, with folders and sub-folders for organization. Create workflows with New Workflow, drag and drop JSON to import, and edit or delete from the card menu. Workflows can be moved between folders; deletion is scheduled (trash) before permanent removal.

Board

An agentic kanban board where cards are persistent jobs. Configure each column with an ordered workflow chain; moving a card into the column runs the chain with the card's full context (content, comments, history, previous outputs). Results are written back to the card — green on success, red on failure, amber while running. Follow-up rounds re-run the current column's chain with everything accumulated so far, which powers iterative planning. Runs are recorded in Execution History with the board trigger source. While a card run is active, Open live opens that exact run on the animated canvas with incremental Debug logs.

Templates

The Templates tab lets you save and reuse workflow templates (full workflows) and node templates (single configured nodes). Create workflow templates from the editor (Share as Template) and node templates by right-clicking a node. Browse by visibility (Everyone or Specific users/teams), apply a template to create a new workflow or add a node to the canvas, and manage your shared templates.

See also Workflows, Teams, and Canvas Features.

Variables

The Variables tab manages the Global Variable Store. Create, edit, and delete global variables; set name, value, and value type (Auto, String, Number, Boolean, Array, Object). Variables are user-scoped and persist across executions. Reference them in any workflow expression as $global.variableName. Variables can be shared with other users or teams.

See also Global Variables, Variable, and Expression DSL.

Chat

The Chat tab is Heym's long-running agent surface for operating the workspace from conversation. Select a credential and model, then ask Chat to answer questions, inspect workflow definitions, run existing workflows, summarize executions and schedules, report which executions are running right now (with elapsed time, current node, and a link to each live run), resolve pending human reviews, create and revise workflows with the same AI Builder engine used in the editor, or add cards to kanban boards with natural language. New cards always start in the selected board's first column; when several boards are available and none was named, Chat presents a board selection before creating the card.

Chat keeps running on the backend after the browser closes. While an answer is streaming, you can send more messages; Heym stores them in a database-backed queue, lets you edit or delete queued messages before they start, and runs them in order when the current response finishes. If the assistant needs planning details and returns clarification questions, the queue pauses until you answer those questions, then resumes after the planning response.

Responses stream with markdown, inline images, workflow preview cards, collapsible tool-call cards, context usage, and automatic context compression. Chat supports attachments, voice input, read-aloud playback, copy actions, quick prompts, User Rules from Settings, and global variables as context.

See also AI Assistant, Credentials, and Settings.

Credentials

The Credentials tab manages API keys and secrets used by nodes. Add credentials by type (OpenAI, Google, Custom, Bearer, Header, Telegram, Slack, SMTP, Redis, RAG: Qdrant + OpenAI, RAG: Psql + OpenAI, Cohere, etc.), name them, and reference them in workflow nodes. Edit or delete from the card; share with users by email or with teams. All values are encrypted at rest and masked in the UI.

Vectorstores

The Vectorstores tab manages vector stores used by RAG nodes. Create a store with a name and a vector store credential — RAG: Qdrant + OpenAI (external Qdrant) or RAG: Psql + OpenAI (Heym's own Postgres via pgvector), which fixes the store's backend — optionally set a collection name, then upload documents (PDF, TXT, etc.). Manage content (view, delete sources), edit store details, and share stores with users. In a RAG node, pick the Database, select the vector store, and run insert or search operations.

See also Qdrant RAG, Credentials, and Teams.

MCP

The MCP tab configures Model Context Protocol integration. Heym supports two modes:

Default server – A single endpoint at /api/mcp/sse exposes all MCP-enabled workflows. View and regenerate your API key, copy ready-to-use client JSON, connect Cursor in one click, or follow the Claude setup flow with automatic OAuth registration.

Named servers – Create multiple isolated MCP endpoints, each with its own UUID-based URL (/api/mcp/servers/{uuid}/sse) and independent API key. Assign specific workflows to each server so different AI clients or teams see only the tools they need. Each named server supports the same auth methods (API key, Claude OAuth) and has its own Copy JSON and Add to Cursor shortcuts. Both endpoints support SSE transport (GET) and Streamable HTTP transport (POST). Toggling a workflow inside a named server moves it to the top of the assigned list so the changed row stays in view.

Heym chat tool – Either mode can also expose the Chat engine as a single heym_chat tool, toggled per surface with its own LLM credential and model (prefilled from your preferred model in Settings). An MCP client sends one natural-language message and the engine does the rest: building, editing and running workflows, analytics, executions, live run status, schedules, boards and cards, teams, global variables, documentation search, and human-in-the-loop decisions. Capabilities added to Chat later are reachable through the same tool with no extra registration. Each call is stored in the Chat tab history as a plug-marked conversation and returns a conversation_id the client can pass back to continue the thread.

See also Agent Architecture, Agent Node, and SSE Streaming.

Traces

The Traces tab shows LLM execution traces. A stats header above the list summarizes the selected time range with KPI cards (Calls, Tokens, Cost, Avg Latency, Error %) and three charts — Tokens by Model, Cost by Model, and Calls Over Time (stacked success vs error). A single Time range selector (1h / 24h / 7d / 30d / All; default 7 days) filters both the charts and the list together. Cost is computed from the per-user LLM Cost Table; models without pricing surface as an inline warning that links to it. Open any trace to see request and response payloads, timing breakdown (llm_ms, tools_ms, mcp_list_ms), tool calls (name, arguments, result), and skills included. Expanded events display JSON—including MCP and JSON-RPC payloads—as a collapsible tree with the first level open by default; Tree / Raw switches back to the original text and malformed JSON remains readable. Use traces to debug Agent Node and LLM behavior and to copy or export payloads.

See also Execution History, Agent Node, and LLM.

Alerts

The Alerts tab defines threshold conditions over a time window and tells you when they are crossed. Four alert types cover the questions operators actually ask: error threshold (did this fail more than N times in the window), workflow duration (did runs get slower, measured as max, average, or p95), token / USD cost (did spend cross a budget, resolved through the same pricing table as Traces), and execution count (did this run far more often than it should have). Every type is judged over a window you choose, never on a single event, because one failed run is noise and a burst is an incident. Alerts watch one workflow or every workflow you can access.

A five-step wizard walks through type, scope, condition, response, and review. The Review step backtests the condition first, reporting how often it would have fired over the last 24 hours to 7 days, so a threshold that is far too low is caught before it is saved rather than after it pages someone. Describe what you want in plain language and AI fills in every step it can, marking its guesses; a partial request still moves the wizard forward, opening on the first step that still needs a decision rather than making you start over. By default an alert fires once and stays quiet until the metric recovers; you can instead have it repeat on an interval.

On the response step an alert can create and assign a new workflow to run when it fires, use one you already have, or do nothing. The firing payload carries the observed value, threshold, window, and the workflows that contributed to the number, which is how alerts reach Slack, email, or Telegram using nodes you already have. Firing history records what was true at the moment each alert fired and is kept for 90 days; acknowledging a firing changes the badge from Firing to Acknowledged without pretending the condition has cleared. The Chat tab can answer what alerts exist and why or when one triggered. Alerts can be shared with users and teams.

See also Analytics, Traces, and Execution History.

Analytics

The Analytics tab shows execution metrics and trends. Summary stats include total executions, success rate, error rate, latency breakdowns, and total Time Saved (from each workflow's estimated minutes saved per run × its successful runs). Select a base time range (24h, 7d, 30d, or all), optionally filter by workflow, then drag across any chart to drill into a selected date range. Charts and workflow tables refresh to the selection, and auto refresh keeps metrics updated. It complements Execution History and the Scheduled view when you need both past results and upcoming runs.

See also Execution History, Scheduled, and Evals.

Dashboard

The Dashboard tab is a Grafana-style space where you build a grid of chart widgets, each rendered from its own hidden Heym workflow. Describe a metric in plain language and the AI generates the widget, or add one manually and pick a chart type: bar, line, area, pie, table, numeric, gauge, scatter, proportion, bar gauge, or text. Widgets cache their results, can be fine-tuned with AI (each change is saved to Edit History), cloned together with their complete workflow, rearranged with Tidy up, and dragged or resized in edit mode. Because each widget is a workflow, any data you can fetch — an HTTP call, a BigQuery query, a RAG lookup, or LLM output — can become a chart.

Evals

The Evals tab (at /evals) lets you create evaluation suites, add or generate test cases, optimize the suite prompt, and run evaluations against Agent Node workflows. Select one or more models, choose a scoring method (Exact Match, Contains, or LLM-as-Judge), optionally configure a separate judge model, set temperature/reasoning effort/runs-per-test, then compare pass/fail and per-model outputs. Review run history for past evaluations and cross-check the underlying behavior in Traces.

See also Agent Node, Traces, and Execution History.

Teams

The Teams tab lets you create and manage teams. Create a team, add members by email, and remove members (creator cannot be removed). Share workflows, templates, credentials, variables, vector stores, and Drive files with teams from their respective share dialogs; all team members gain access. Edit team name and description or delete the team (removes all team shares).

Scheduled

The Scheduled tab shows all active Cron workflows on a visual calendar. Switch between day, week, and month views to see when your automations are scheduled to run, then jump back to the related workflow when you need to edit the schedule.

See also Cron, Analytics, and Execution History.

Logs

The Logs tab shows Docker container logs for the Heym stack (backend, frontend, PostgreSQL). Select container(s), filter by log level (All, INFO, WARNING, ERROR, DEBUG), and search within logs. Use it for debugging and troubleshooting. For workflow execution logs (node results, outputs), use Execution History, Traces, or the Debug panel in the editor instead.

See also Execution History, Traces, and Canvas Features.

DataTable

The DataTable tab lets you create and manage structured data tables within Heym. Define typed columns (string, number, boolean, date, JSON), manage rows with inline double-click editing, import/export CSV, and share tables with users or teams with read/write permissions. Use the DataTable node to access tables programmatically in workflows. A pinned System tables section at the top hosts the LLM Cost Table: a fixed-schema view of per-model pricing seeded from Helicone in the background (24-hour TTL, manual Refresh), where each user can override prices or add custom rows for models Helicone does not list. These pricing rules drive the cost KPI and the per-model cost chart on the Traces tab.

See also DataTable node, Traces, Workflow Structure, and Teams.

Drive

The Drive tab shows all files generated by skills across your workflows. It lists each file with name, type, size, source node, creation date, and team-sharing state, and provides search, authenticated download, share, delete, and pagination controls. It is the dashboard companion to File Generation, the Drive reference, and the Drive node.

See also Drive, File Generation, and Drive node.