Skip to content
FalangFalang
falang.ioRU

Workflow builder

What the workflow builder is

Section titled “What the workflow builder is”

Falang’s workflow builder is a visual editor for automations — integrations between services, bots and AI scenarios — built on the same scheme engine as the logic constructor, but aimed at long-running, reliable scenarios: handling messages from bots, incoming webhooks, calls to external services, waiting for events, and manual approval steps.

Unlike classic no-code integrators, every running scenario executes as a Temporal workflow — a durable-execution platform. That gives you, out of the box:

  • automatic retries when an external call fails;
  • timers and long waits with no polling and no risk of losing state;
  • recovery after a process crash — the scenario resumes exactly where it left off;
  • a full execution history for every run.

This sets Falang apart from typical low-code BPM tools aimed at business analysts, and from simple integrators with no delivery guarantees — it’s an engine for developers who need corporate-BPM-grade reliability without a heavy implementation cycle.

Core concepts

Section titled “Core concepts”

  • Project — a container for documents: functions, trigger functions, object structures (data types), and the project’s integrations document. The project list shows the most recently edited projects first.

  • Function — an ordinary algorithm scheme, same as in the logic constructor.

  • Trigger function — a document started by an external event (a Telegram message, an incoming webhook, etc.) and executed as a workflow.

  • Build & Run — compiles every function in the project and runs it as a worker, available for a test run (a dev version).
  • Publish — promotes the current code to a stable (prod) version, with the ability to roll back to any earlier version.

  • Run — starts a function document on the dev stand and follows it live: the icon it’s currently on lights up on the canvas as it executes, and a side panel shows its status, event history and run journal. The same panel can follow any other execution (dev or published) picked from the project’s own run list.

  • Debug — like Run, but you can set breakpoints on any statement first: execution pauses there, the paused icon is highlighted, and a side panel lists every variable in scope. See Debugging.

  • Files and Tasks — project tabs next to Runs: the files your scenarios stored, and the decisions they are waiting on from you. See Files and Tasks for people.

  • Agent and History — the right-hand sidebar: an AI agent that builds and edits the project from a plain-language description, and the project’s version history.

Project layout

Section titled “Project layout”

The project tree always starts with the Integrations document followed by three fixed sections: Triggers (trigger functions), Functions and Types (object structures). Each document type lives only in its own section — you can create your own nested folders inside a section, but a document can’t be moved to a section that doesn’t accept its type, and the sections themselves can’t be renamed, moved or deleted. The AI agent and the MCP server follow the same rules.

Document names are unique within a project (case-insensitively, across all document types). Right-click a document or a folder in the tree and choose Rename to change its name (function names must stay English camelCase). The page address (#/projects/…/documents/…) follows the open project and document, so a reload or the browser’s Back button brings you to the same place, and each project remembers its open tabs. When you create a trigger you pick one of the project’s credentials (integration instances); integrations that need none, such as a schedule, are offered in a separate group.

Next

Section titled “Next”