V1 and V2
Flowgear supports v1 Runtime Workflows and v2 Runtime Workflows in the same Site. The surrounding platform objects and management screens are shared, but Workflow design, execution, triggers, Connections, and local placement are runtime-specific.
Choose the documentation for the Workflow you are working with:
- v1 Runtime covers the established visual designer and DropPoint execution model.
- v2 Runtime covers the declarative, compiled Workflow model and Cluster placement.
Use an AI assistant to help move an implementation from v1 Runtime to v2 Runtime. The Sub-Workflow Node can call v1 Runtime Workflows from a v2 Runtime Workflow. This is a helpful way to progressively migrate large solutions.
Choose a runtime
For a new integration, evaluate the v2 Runtime's compiled Workflow model, structured mapping, streaming, and assistant-supported authoring against the systems and operations you need. Check the Node catalog for the required runtime and Method, including its Connection and local execution requirements. A familiar Node name does not establish that the two runtime versions have identical contracts.
For an existing v1 Runtime integration, review the benefit and scope of migration before changing a working implementation. You can continue to operate it alongside v2 Runtime Workflows and move a bounded part of the solution first.
| Area | What to check when moving to the v2 Runtime |
|---|---|
| Workflow design | Replace v1 Runtime Node and Flow Connector orchestration with ordered Steps and explicit containers. See Execution Order. |
| Data mapping | Map structured Objects and Arrays through Expressions and retain the schemas required by consumers. See Data Mapping. |
| Triggers | Recreate the intended HTTP, schedule, listener, or MCP contract using the selected v2 Runtime Method. See Triggers. |
| Local systems | Select a Cluster for the whole v2 Runtime Workflow and verify Node support. A v1 Runtime DropPoint assignment does not select its execution location. See Local System Integration. |
| Connections | Create compatible v2 Runtime Connections and configure values in each Environment. See Create a Connection. |
| Failure and recovery | Check both exceptions and per-record results, and preserve idempotency across retries. See Error Handling. |
Validate a migration incrementally
- Record the existing integration's inputs, outputs, triggers, dependencies, and external side effects.
- Confirm that the required v2 Runtime Nodes and Methods cover that contract before rebuilding it.
- Build a small path in Test, using the assistant or manual designer as appropriate.
- Compare representative success, empty-input, failure, and retry outcomes with the existing integration.
- Configure Environment-specific Connections, API-key authorization, Cluster selection, and capacity before release.
- Plan the trigger cutover so both implementations do not unintentionally process the same production events.
An assistant-generated design still needs the same contract review and operational tests. A v2 Runtime parent that calls a v1 Runtime Sub-Workflow also retains that child's runtime dependencies until the child is migrated.