An automation platform with versioned integrations, published flow snapshots and separately executed workflow jobs.
This visual workflow automation case study centres on one question, namely what happens to a flow after it is released. An author connects applications in a visual builder by arranging triggers, actions and conditions. The platform runs the flow and records each step result. The builder also covers code, loops and delays for work that a single integration action cannot. Approvals and sub-flows handle the rest.
Our main focus was what happens once a published flow changes.
The challenge
Editing a live automation must never touch the version that is already out there handling requests. Releasing an integration package should not quietly swap a dependency either. Workers need enough access to run a flow, yet they must not hold direct credentials for the application's databases. We routed that access through the application API.
What we built
A flow can begin from a webhook, from a schedule or from a submitted form. Integration packages declare their inputs, triggers and actions. Those definitions drive both the builder's input fields and its runtime calls alike. Custom packages bring internal systems into the same catalog.
A webhook resolves to the published version. A request that needs no immediate result is acknowledged once it is queued, while a caller that wants the flow's answer waits for it. Run history exposes the progress, the step results and the logs.
A published flow stays fixed
Publishing locks a flow version and updates its published reference in one database transaction. Editing that flow creates a draft. The draft takes over only after another publication. A frozen dependency manifest fixes the integration versions the flow uses. The bundle still needs checking before release, since keeping a version does not prove its contents are right.
Workers use the application API
Workers obtain jobs and report progress through the API, with no direct PostgreSQL or Redis credentials. A separate process loads the flow's settings and runs its steps. Isolated code execution is available, though worker concurrency and memory limits still need configuration.
Acknowledged work first sits in Redis. Its database-backed run record appears only when a worker starts execution, which makes Redis persistence and recovery essential for jobs still waiting to start. Integration packages can be maintained apart from the main application. Built-in tables and a key-value store hold the operational data a flow needs.
Project success
Authors can keep working on a draft while the published snapshot carries on serving requests. The flow and its package versions form one release. When execution needs attention, the step results and the run logs together show exactly where to look. Workers report through the application API without ever holding database credentials.
Technology stack
Application
TypeScript, Node.js, Fastify
Interface
React
Data access
TypeORM, PostgreSQL
Queue infrastructure
Redis, BullMQ
Code execution
Separate processes, isolated-vm
Integration packaging
Versioned npm packages
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
