Skip to main content
Deployment models:
  • Self-Hosted Features for self-hosted deployments
  • All Deployments Features available in both self-hosted and SaaS

​
What 5.9.0 includes

  • Closes the runtime authorization rewrite. Per-environment sharing, project-version-scoped roles, data-sync Keycloak provisioning.
  • Brings the full set of changes accumulated since the 5.1.x LTS line. Conversational AI, UI Flows, Custom Components, AI Platform, runtime authorization.
  • Ships a new React Native SDK and rounds out iOS UI Flow support.
5.9.0 is the first LTS in the 5.9.x family (target 2026-06-02). Monthly LTS patches follow from July 2026. Self-hosted customers upgrading from 5.1.x LTS go directly to 5.9.0. See the Migrating from 5.1 LTS guide for the consolidated upgrade path.
What’s in this LTS release?
🔐 Runtime authorization completion - Per-environment sharing checklist, project-level end-user roles, data-sync provisioning of Keycloak groups and roles.
🌐 Anonymous runtime access - Built-in Anonymous role + Share modal “Everyone with the link” for unauthenticated end users; session-bound, SDK auth-skip mode.
🛡️ Runtime authorization overhaul - Project-version-scoped roles, end-user groups moved from Keycloak into FlowX, Solutions → Share modal flow, Active Policy gate, designer-user bypass.
🔒 UI Flow permissions - Per-UI-Flow role allow-list with runtime 403 enforcement; assignments travel with import/export.
👥 End-user access management - Org-level End-Users, End-User Roles, End-User Groups separate from Designer users; CSV bulk invite.
🎯 Active policy: group overrides - Override a project’s active build per runtime group; legacy role overrides are excluded from runtime resolution and only kept for deletion.
🧩 Roles carried across project-version merges - Application-version roles cloned onto the merged version automatically, no manual re-binding after merge.
🏷️ Operations-editor role - Workspace operations editor role and wks_process_instance_variables_edit permission for ops teams.
🗂️ Cross-workspace projects - Import the same project into multiple workspaces in the same environment.
🔁 Cross-LTS import/export - Move project versions and builds between the 5.1.x and 5.9.x LTS lines, in both directions.
🚪 Log-in page redesign - IdP provider button replaces the fallback link; refreshed labels across the log-in flow.

​
Runtime authorization completion

5.9.0 completes the project-version-scoped runtime authorization model:
  • Sharing checklist for environment promotion. Sharing assignments do not export with builds. Each environment must be reconfigured when a project is promoted. The deployment checklist for this is now part of the setup guide.
  • Project-level end-user roles. Roles can be assigned at the project level from creation, so a fresh project is reachable without a separate share pass.
  • Data-sync provisioning. The data-sync job calls the Keycloak admin API on first run to provision FlowX-managed end-user groups and runtime roles. Five new FLOWX_OPENID_* env vars expose the admin credentials.
Self-HostedAll Deployments

Documentation

See Setup guides → Access management → Runtime authorization for the day-to-day model.
  • Per-environment sharing checklist. When you promote a project from dev to uat to prod, the Share modal assignments do not travel with the build. The setup guide now documents the explicit per-environment reconfiguration step.
  • Project-level end-user roles. Assign end-user roles at the project level so a freshly created project is reachable on day one. No separate Share-modal pass required for the default access pattern.
  • Data-sync Keycloak provisioning. The data-sync job provisions FlowX-managed end-user groups and runtime roles in Keycloak the first time it runs against a 5.9.0 environment. Configure admin credentials with the new FLOWX_OPENID_* env vars on the data-sync job.
  • Deployment checklist included. The runtime authorization setup guide now ships a deployment prerequisites section so the data-sync OpenID config and per-environment sharing reset are part of the standard promotion runbook.
Required on the data-sync job from 5.9.0 onward:
Environment VariableDescriptionDefault
FLOWX_OPENID_PROVIDEROpenID provider type. Set to keycloak.keycloak
FLOWX_OPENID_SERVERURLBase URL of the Keycloak server, including the /auth/ path.-
FLOWX_OPENID_USERUsername of a Keycloak admin account that can manage groups and roles in the FlowX realm.-
FLOWX_OPENID_PASSWORDPassword for the admin account above. Store in a Kubernetes Secret.-
FLOWX_OPENID_CLIENTIDKeycloak admin client used to obtain the admin token. Set to admin-cli for standard Keycloak deployments.-
See Data-sync job setup → OpenID provider configuration for the full setup.

​
Anonymous runtime access

5.9.0 introduces unauthenticated runtime access: an app can be made publicly reachable, and processes or UI flows inside it can be opened to anonymous end users via a new built-in role.
  • Two independent gates. The app must be set to Everyone with the link in the Share modal AND the process or UI flow must have the Anonymous role assigned. If either gate is closed, the runtime returns 403 Forbidden (Anonymous access not enabled for this application / Anonymous access not enabled for this build).
  • System-level Anonymous role. Auto-seeded on every new app version, cannot be deleted or edited; allowed operations are VIEW, EXECUTE, and an auto-populated SELF_ASSIGN.
  • Session-bound traffic. Anonymous requests carry an X-Fx-Anonymous-Session-Id header. The backend issues a new session ID on first contact; instances are bound to that session and cannot be read by another.
  • SDK auth-skip. The renderer decides authenticated vs anonymous from the authToken parameter at initialization. Token-in-storage on the same browser silently bypasses anonymous mode — container apps must scrub the Authorization header on public routes.
Self-HostedAll Deployments

Documentation

See Platform deep-dive → User roles management → Anonymous runtime access for the full feature reference.
  • Share modal public-access option. A new General access section in the Share modal switches between Everyone with the link and Only invited users and groups. Default remains invited-only.
  • Anonymous role on processes, UI flows, and reusable UI templates. Selectable in the Permissions tab once the role is on the version; additive to other roles.
  • Component hide / disable rules. UI Designer supports an Anonymous condition in role-based hide/disable rules at the component level.
  • Public-build asset rule. When a build has the Anonymous role and the app is shared publicly, all assets inside (enumerations, substitution tags, media files, themes, fonts) become reachable anonymously — except UI flows and processes that don’t carry the Anonymous role.

​
Runtime authorization overhaul

Project-version-scoped roles, end-user groups in FlowX (moved from Keycloak), Solutions → Share modal, Active Policy gate, designer-user bypass, swimlane roles.All Deployments

Documentation

Open the Runtime authorization overhaul documentation.

​
UI Flow permissions

Per-UI-Flow role allow-list with runtime 403 enforcement, per-component hide/disable, and assignments that travel with import/export.All Deployments

Documentation

Open the UI Flow permissions documentation.

​
End-user access management

Org-level End-Users, End-User Roles, End-User Groups separate from Designer users; CSV bulk invite.All Deployments

Documentation

Open the End-user access management documentation.

​
Operations-editor role

New Workspace operations editor predefined role and wks_process_instance_variables_edit permission for ops teams to migrate tokens and edit variables.All Deployments

Documentation

Open the Operations-editor role documentation.

​
Cross-workspace projects

Import the same project (UUID) into multiple workspaces in the same environment for UAT / Staging emulation.All Deployments

Documentation

Open the Cross-workspace projects documentation.

​
Cross-LTS import/export

Move project versions and builds between the 5.1.x and 5.9.x LTS lines, in both directions. A newer platform version imports exports produced by an older one, and exports produced on a newer version can target an older one — useful for shipping a hotfix to an environment that hasn’t been upgraded yet. Compatibility is patch-agnostic: any 5.9.x patch works with any 5.1.x patch.When exporting to an older version, resources whose type doesn’t exist there are excluded automatically and listed in a manifest_excluded.json file in the archive, so the import still succeeds. The lowest version in the export/import path defines the usable functionality.Self-Hosted

Documentation

Open the Cross-version export and import documentation.

​
Active policy: group overrides

Active policy overrides can now target runtime groups instead of runtime roles. The override resolves the active build for every member of the group at runtime, with a priority field deciding which group wins when a user belongs to several.Role-based overrides are deprecated in the same change. The Role override type is gone from the Add / Edit modal, and any role overrides carried over from a 5.1.x upgrade are kept in the table for visibility only — they are flagged DEPRECATED, excluded from runtime resolution, and can only be deleted.All Deployments

Documentation

See Projects → Runtime → Active policy for the full configuration model.
  • Group override type. Add / Edit Policy Override now exposes Username and Group. The group picker lists runtime groups that have a runtime role configured for the current project.
  • Priority is mandatory and unique per project for group overrides. Lower numbers win when several groups match the same user. Username overrides ignore priority and always take precedence.
  • Resolution order. Username override → Group override (lowest priority wins) → Global policy.
  • Role overrides deprecated. Removed from the Add / Edit modal. Existing role rows are rendered muted with a DEPRECATED marker and a red banner; only the delete action remains. Deprecated role overrides are excluded from runtime resolution.
  • Test panel. The effective-policy test panel simulates resolution for a given user.
  • Audit log. Group override create / update / delete / enable / disable events are recorded.
Upgrading from 5.1.x carries existing role overrides into the new table as deprecated entries. They no longer affect runtime behavior. Recreate the intended access using group overrides and delete the role rows. See Migrating from 5.1 LTS → Runtime authorization for the conversion steps.

​
Roles carried across project-version merges

Application-level role definitions are now carried into the merged project version automatically. Before 5.9.0, merging two project versions could leave the role table in a partial state. Bindings defined on one side were not consistently propagated to the merged version. 5.9.0 clones the roles from the destination latest version onto the merged version atomically as part of the merge transaction, so merges with role changes complete without follow-up manual cleanup.All Deployments
  • Roles propagated as part of the merge. When a project version is merged, application-version roles from the destination latest version are cloned onto the merged version in the same transaction.
  • No manual role re-binding after merge. Operators no longer need to re-apply role bindings on the merged version. The merge completes in a single commit; the merged version is immediately usable.

​
Log-in page redesign

The Designer log-in page is refreshed to align with the platform’s design system. When an organization has an external IdP configured, the previous fine-print fallback link is replaced with a primary button labeled with the IdP configuration’s Display name. Field labels and call-to-action copy across the log-in flow are aligned with the rest of the UI.All Deployments
  • IdP provider button. When the organization has an IdP configured, the log-in screen surfaces a primary button labeled with the IdP’s Display name, instead of a fine-print link below the form.
  • Refreshed copy. Updated labels across the flow: Log In replaces Sign In, Reset Password replaces Forgot password?, and the page title becomes Log In.

​
Chat component

Standalone chat tab in web container apps with AI agent integration and session persistence. Inline / Floating / FullScreen display modes + iOS and Android mobile support. Chat History and Suggested Prompts. Markdown rendering.All Deployments

Documentation

Open the Chat component documentation.

​
Conversational Workflows

Chat Driven workflow type, multi-turn dialogue, Chat Session ID + User Message Start node, direct chat reply.All Deployments

Documentation

Open the Conversational Workflows documentation.

​
Voice input + Speech-to-Text

Audio recording, preview, and send within chat; Speech-to-Text node for transcription.All Deployments

Documentation

Open the Voice input + Speech-to-Text documentation.

​
Memory capabilities

Built-in session memory: last 3 turns of the conversation, with a Use Memory toggle on the Custom Agent.All Deployments

Documentation

Open the Memory capabilities documentation.

​
Intent Classification node

Dedicated node combining LLM classification + branching, up to 10 intents, If-No-Intent-Matches fallback.All Deployments

Documentation

Open the Intent Classification node documentation.

​
Chat-based UI Flows

UI Flows expose a Flow-Based vs Chat-Based experience type set at the UI Flow level.All Deployments

Documentation

Open the Chat-based UI Flows documentation.

​
AI Triggers

Named parameterized message templates to launch conversational workflows with context.All Deployments

Documentation

Open the AI Triggers documentation.

​
Stop agent response

Stop button replaces Send while streaming; cancels the underlying workflow and persists a cancelled flag.All Deployments

Documentation

Open the Stop agent response documentation.

Chat sessions now get a meaningful title generated automatically from the user’s first message. No more “untitled chat” entries in the history. End users can also search across all their conversations with a single query that scans both message bodies and session titles.All Deployments
  • Auto-generated session title. The first user message seeds a provisional title (first 7 words). A one-shot LLM call then refines it into a concise descriptive title; the chat list updates live via an SSE event.
  • Conversation search. /api/conversations accepts a q query parameter (2–200 characters). Matches against both session titles and message bodies. Each result carries a snippet field showing the matched excerpt.
  • Title update event. When the LLM title is generated, the gateway emits a chatSessionRenamed event on the chat session channel; the chat list shows the refined title on the next load.
  • Single-shot generation. Title generation runs exactly once per session, on first persist. The provisional 7-word title remains in place if the LLM call fails. No error surfaces to the end user.

​
Evaluations

5.9.0 introduces Evaluations: score AI node outputs against test cases using LLM-as-judge, RAG-quality, and code evaluators. Attach datasets to AI nodes, launch experiments, and read per-evaluator aggregate scores plus per-test-case details.
  • 10 built-in evaluators across three categories. LLM-as-judge (Correctness, Conciseness, Hallucination, Answer relevance), RAG (Groundedness, Helpfulness, Retrieval relevance), and Code (Exact match, Levenshtein, JSON match). Numeric evaluators ship with default thresholds; binary evaluators return pass/fail.
  • Datasets attached to AI nodes. Test cases sourced manually or captured from real node executions. The dataset persists a schema snapshot so older runs remain reproducible if the workflow changes underneath.
  • Async judge pipeline. A new Python evals-judge event-driven worker consumes ai.flowx.ai-platform.evals-judge.job.request.v1, scores each (test case × evaluator) pair via the configured judge LLM, and publishes back on the response topic. Unscored jobs land on a DLQ for manual review.
  • Per-org judge model. A new EVAL capability is registered in the org-manager LLM catalogue. Platform default is gpt-5.4-mini, backfilled per org on upgrade so evals work out-of-the-box.
All Deployments

Documentation

See AI Platform → Evaluations for the user workflow, evaluator catalogue, REST API surface, and operator setup.
  • Designer workflow. Add a dataset on an AI node, add test cases (manually or captured from a node execution), pick evaluators, launch an experiment, read aggregate + per-test-case reports.
  • LLM-as-judge scoring. A judge LLM reads the model output (and optional expected output) and scores it on a single rubric, returning a numeric score plus its reasoning.
  • RAG-quality scoring. Judges the retrieval side of a RAG workflow — is the retrieved context grounded, helpful, and relevant?
  • Deterministic code evaluators. No LLM call. Exact match, normalized Levenshtein, and JSON-shape match against the dataset’s output contract.

​
PII Guard: per-entity detections on documents and images

PII Guard scans on document and image AI nodes now surface the same per-entity detection list already shown for text scans. The run console reports each match with its entity type, confidence, original value, and replacement, making it easy to verify what was redacted on file-based AI inputs.All Deployments
  • Same shape as text scans. Document and image scans now return a detections list with entityKey, confidence, originalValue, replacement, and direction, matching the existing text-scan output.
  • Bounding regions for document and image hits. Each detection on a DOCUMENT or IMAGE source includes regions (x, y, width, height) so the run console can highlight where the entity was matched.
  • Source-type tagging. Detections carry a sourceType of TEXT, DOCUMENT, or IMAGE, mirroring the wrapper’s sourceType field so audit consumers can attribute matches to the right payload.
  • Backward-compatible upgrade. On older data-privacy versions that don’t yet return the analyzer pass for object endpoints, detections stays empty and the redacted artifacts continue to be produced and downloadable.

​
Custom Agent nodes

AI agents that use MCP tools to act autonomously inside workflows.All Deployments

Documentation

Open the Custom Agent nodes documentation.

​
MCP integration

MCP servers as data sources; tools available in Custom Agent nodes; OAuth 2.0 SA auth, with BEARER/BASIC. 5.9.0 adds runtime config-param references (${yourParamName}) inside MCP server configuration fields for environment portability.All Deployments

Documentation

Open the MCP integration documentation.

​
Knowledge Bases

Centralized KBs with PDF upload, workflow ingestion (Append / Replace / Delete), semantic search, and Custom Agent integration. Stores rename + typed filter builder; system metadata + Kafka indexer/embedder + Qdrant delete + FILE_PATH ingestion. 5.9.0 adds tunable Qdrant prefetch and fusion limits for hybrid search — deployment-time settings, covered in the deployment guidelines.All Deployments

Documentation

Open the Knowledge Bases documentation.

​
AI Providers self-service

Org-level OpenAI (BYOK / FlowX-Managed) and Azure OpenAI; Defaults & Fallbacks per capability + workspace type; Audio capability.All Deployments

Documentation

Open the AI Providers self-service documentation.

​
Extract Data from File

LLM / OCR / Text Parsing strategies; image input (JPG, PNG, TIFF); signature detection.All Deployments

Documentation

Open the Extract Data from File documentation.

​
Web Page Extractor / Web Crawler

Crawl web pages, static or dynamic URLs, link-following depth, PDF extraction. URL filtering and file downloads; multi-URL filters.All Deployments

Documentation

Open the Web Page Extractor / Web Crawler documentation.

​
Context Retrieval

RAG search against KBs without an LLM; hybrid / semantic / keyword; metadata filters and re-ranking. 5.9.0 surfaces per-chunk relevance scores in the node output so downstream nodes can branch or filter on confidence.All Deployments

Documentation

Open the Context Retrieval documentation.

​
AI Developer generates Custom Components

Pre-built agent drafts React Custom Components (JSX, CSS, package.json, sample data) from a brief.All Deployments

Documentation

Open the AI Developer generates Custom Components documentation.

​
Operational prompt split

The single Operation Prompt field on AI nodes is split into two inputs so the static portion of the prompt can be cached by the LLM provider while dynamic values are passed separately. Instructions holds the agent’s role, tasks, and expected I/O, sent as the System message and cached between executions, so ${} dynamic values are not allowed. The Context field, inside the Background section, takes the dynamic per-execution prompt text and supports ${} references, sent as the User message and not cached.All Deployments
  • Instructions: cached System message. Mandatory. Holds the agent’s role, tasks, and expected input/output. Sent as the System message and cached by the LLM between executions. ${} references are rejected to keep the cache key stable.
  • Background section: dynamic User message. Wraps the Knowledge Base selector, the Context textarea (free text with ${} support), the Use only referenced values as input toggle, and, in Chat Driven workflows, the Use conversation memory toggle. Sent as the User message on every execution; not cached.
  • Lower LLM cost and latency. The static portion of the prompt is sent once per cache window instead of on every execution, so each call pays only for the dynamic Background section. The longer the Instructions, the bigger the per-call saving.
  • Applies to every AI node subtype. The split UI is now shared by all AI node subtypes that previously used the single Operation Prompt field.

​
Manage Knowledge Base content from Runtime

A new Test KB option on the build is available in runtime, giving operators visibility into Knowledge Base content that was previously opaque after deployment. Authorized users can inspect chunks, add or replace sources, edit metadata, and query the KB without going back to the Designer. Useful for debugging retrieval issues and keeping KBs current as business knowledge evolves.All Deployments
  • Six runtime operations. Create store, Append content, Replace content, Delete store, Edit metadata, and Query. All from the Test KB option inside the running app.
  • Files and payloads. Both file uploads and inline payloads can be added to the KB through this feature.
  • Permission-gated. KB management at runtime is controlled by runtime authorization, so only users with the right role see the Test KB controls.
  • Visibility into chunking. Inspect how documents were chunked and what metadata was captured, useful when debugging retrieval quality on client-uploaded content.

​
UI Flows

5.9.0 closes the UI Flows feature: reusable, multi-platform UI (web, iOS, Android) as first-class project resources with their own lifecycle and runtime sessions. UI Flows now reach feature parity with processes for end-user-facing apps that don’t need a BPMN process underneath.
  • Multi-platform. Author once in the Designer; UI Flows render on web (React), iOS, and Android via the platform-specific renderers. Layouts and component bindings travel together as a single resource.
  • Sessions and runtime monitoring. Each UI Flow run is a UiFlowSession with its own state, navigation history, and SSE event stream. Operators can monitor and inspect sessions from the runtime.
  • Process integration. UI Flows can start processes (Start Process action), navigate to other UI Flows (Navigate UI action), and embed a Process Renderer to show a running process inside a UI Flow. Workflows can also be invoked from a UI Flow with a Start Workflow action.
  • Per-UI-Flow permissions. A dedicated Permissions tab on each UI Flow controls which roles can run it. Runtime enforces with 403; assignments travel with import/export.
All Deployments

Documentation

See Building blocks → UI Flows for the full feature reference, including Navigation Areas, session variables, route management, and the component reference.
  • Navigation Areas. Group UI components into named areas for layout, scroll, and per-area transitions.
  • Start Parameters and Session Variables. Pass typed inputs into a UI Flow at start; persist state across nodes via Session Variables.
  • Route management. Each UI Flow exposes a stable runtime route; nested navigation preserves browser history and back/forward behaviour.
  • Task Manager component. Drop the Task Manager surface inside a UI Flow to drive process tasks from the same UI shell.
  • onClick and On Display events, plus a new On Load event. Component-level events trigger workflows or UI actions, with the new On Load event firing when the UI Flow first opens.
  • Breadcrumbs. Built-in breadcrumbs reflect the Navigation Area hierarchy and follow the active theme.
  • Process Renderer + Start Workflow action. Embed a running process inside a UI Flow; trigger an integration workflow from a button or event without leaving the flow.

​
Custom Components

Write React JSX / CSS in the Designer. React, Emotion, Lodash, Axios, date-fns supported. Input keys + actions, import / export. Custom Components in Processes (with INPUT/OUTPUT mappings).All Deployments

Documentation

Open the Custom Components documentation.

​
Process Renderer in UI Flows

Embed process renderers inside UI Flows.All Deployments

Documentation

Open the Process Renderer in UI Flows documentation.

​
UI Flow sessions monitoring

Runtime view with session list, audit log, process tracking, workflow debugging.All Deployments

Documentation

Open the UI Flow sessions monitoring documentation.

​
Accessibility (WCAG 2.1 AA)

Accessibility section in the UI Designer with ARIA, keyboard navigation, screen reader support across web / iOS / Android. Mobile accessibility expanded.All Deployments

​
New theme components

Tooltip, Markdown, Progress Bar, Separator components across React / Angular / Android.All Deployments

Documentation

Open the New theme components documentation.

​
Multi-file bulk upload

Multiple File Upload component on process screens and UI Flows. Angular and React SDK support; single bulk endpoint + one SSE completion event.All Deployments

Documentation

Open the Multi-file bulk upload documentation.

​
Card default collapse + Tables in Collections

Cards configurable to load collapsed; Table UI components inside Collection prototypes.All Deployments

Documentation

Open the Card default collapse + Tables in Collections documentation.

​
Event Handlers

The UI component configuration panel introduces a dedicated Event Handlers section. The legacy flowx_props bag is replaced by a typed, per-handler form covering action type, optional analytics, custom body, destination, and collection save-key fields. Container components (Page, Zone, Modal, Tab Bar in UI Flows; Tab on process screens) and inline components resolve their actions through the same model.Existing UI events and AI triggers are migrated automatically. A Liquibase migration runs on the first 5.9.0 boot and moves the data into the new ui_action model. No project re-export or re-import is required.All Deployments
  • Typed Event Handlers. Each handler is a named, typed entity instead of a free-form prop, making configuration easier to validate and audit.
  • Action type selector. Pick the action type from a dropdown that knows which fields are required for that type.
  • Analytics, body, destination, save-key. Per-handler sub-forms cover analytics events, custom request bodies, destination resolution, and collection save-key fields.
  • Unified for inline and container components. Page, Zone, Modal, and Tab Bar containers in UI Flows use the same Event Handlers model as inline components; on process screens, Tab containers use it.

​
Theming and Designer polish

Form field labels, error messages, and helper text gain padding controls and scoped style variants in the theme model. Theme Admin exposes the new padding properties on segmented buttons, sliders, and input selections; the React and Angular SDKs apply the values in the renderers; the Designer preview reflects them in place. Form fields also pick up a consistent mandatory label style applied automatically when a field is required.
  • Scoped variants for labels, errors, helpers. Theme configs can override label, error, and helper styles per component without affecting other parts of the form.
  • Padding for segmented buttons, sliders, input selections. Theme Admin adds label, error, and helper padding controls for these components; values flow through to all renderers.
  • Mandatory label style. A consistent style for mandatory-field labels, applied automatically when a form field is required.
  • Designer preview parity. Theme overrides and paddings are visible in the Designer preview without round-tripping through a runtime app.
All Deployments
The command center floating action button is now hidden on the running-instance screens of Processes, UI Flows, and UI Templates, where it overlapped with the instance view; it reappears when the instance data panel is open. The command center remains reachable through the standard keyboard shortcut and from screens where it does not interfere.All Deployments

​
Email Trigger

New data source: IMAP-triggered processes, attachments routed to the document-plugin, validation rules, Manage Triggers UI. Resource management, reply-to, and mock-email testing.All Deployments

Documentation

Open the Email Trigger documentation.

​
Microsoft Outlook data source

Microsoft Graph integration via Azure AD; Read / Send / Read&Send scopes; conversation threads.All Deployments

Documentation

Open the Microsoft Outlook data source documentation.

​
Incoming Webhooks

New webhook-gateway microservice; trigger processes via HTTP POST with API key auth. Provider adapters for Slack (HMAC-SHA256 + timestamp skew) and Meta (verify-token handshake + X-Hub-Signature-256). 5.9.0 adds Resume Process from intermediate catch events and the Meta provider. See the 5.9.0 cards above.All Deployments

Documentation

Open the Incoming Webhooks documentation.

​
Oracle Database integration

Oracle 21c / 23ai data source; schema-aware Monaco editor; SERVICE_NAME or SID; SSL. Beyond tables and SELECT, queries can also target views, functions, and stored procedures, with output parameters returned to the workflow.All Deployments

Documentation

Open the Oracle Database integration documentation.

​
Unmanaged MongoDB data source

Connect to externally managed MongoDB 6.0+ instances with the same CRUD as the FlowX DB. 5.9.0 adds a visual query builder for Unmanaged Mongo (filter / projection / sort, generated-query preview, in-place result preview).All Deployments

Documentation

Open the Unmanaged MongoDB data source documentation.

​
File Storage data source

A new data source connecting workflows to external file storage — FTP, SFTP, S3 / S3-compatible, or Azure Blob Storage. Define named List, Download, Upload, Delete, and Move operations scoped to a root path, browse and test them in Designer, and call them from a Data Source node. Operations run in the new file-gateway service, exchanging files with the document-plugin.All Deployments

Documentation

Open the File Storage data source documentation.

​
Send Notification action + Email Sender

SMTP data source and a new action that sends or replies email directly without going through Kafka.All Deployments

Documentation

Open the Send Notification action + Email Sender documentation.

​
Advanced Query Builder

Visual query builder replacing manual JSON. New operators (exists, contains, before, after, etc.).All Deployments

Documentation

Open the Advanced Query Builder documentation.

​
Parallel branches in workflows

Start / End Parallel nodes for concurrent execution in Integration Designer.All Deployments

​
REST endpoint caching + workflow partitioning

TTL-based caching for REST GETs (Expires After / Expires At); time-based workflow partitions (DAY / WEEK / MONTH) with retention.All Deployments

​
Data mappers + workflow data models

Workflow data models with input / output; process ↔ workflow mapping; CRUD endpoints.All Deployments

Documentation

Open the Data mappers + workflow data models documentation.

​
Proxy Server Connections

Reusable HTTP/HTTPS proxies attached to REST data sources.All Deployments

Documentation

Open the Proxy Server Connections documentation.

​
Faster authoring loop

5.9.0 adds inline test modals on Script nodes and per-subworkflow individual runs. Iterate on script code or run a single subworkflow node without leaving the canvas.All Deployments

​
Meta webhook provider

Incoming Webhooks add Meta as a built-in provider alongside Generic and Slack, covering WhatsApp, Messenger, Instagram, and Threads. The webhook-gateway handles the Meta-specific subscription handshake and signature verification natively. No custom adapter code required to wire a Meta-platform integration into a FlowX process.All Deployments
  • Subscription handshake. The gateway answers Meta’s GET URL-verification request by validating hub.mode=subscribe and the provided hub.verify_token against the configured verify token, then echoes hub.challenge back. Constant-time token comparison.
  • X-Hub-Signature-256 verification. Every POST is authenticated with the X-Hub-Signature-256 HMAC-SHA256 signature using the configured app secret. Requests with missing or invalid signatures are rejected before reaching the process engine.
  • Two secrets per webhook. When you create a Meta webhook in Integration Designer, two masked inputs appear in the configuration panel: Verify token (used during the handshake) and App secret (used for signature verification). Both are required.
  • Multi-product support. A single Meta webhook can receive events from WhatsApp, Messenger, Instagram, and Threads. The provider is configured at the webhook level; the channel is part of the payload.
Select Meta in the provider dropdown when creating the webhook data source. Both secret fields are required:
FieldDescription
Verify tokenThe token Meta sends back during the GET URL-verification handshake. Choose any string; configure the same value on the Meta App developer console.
App secretThe App secret from the Meta App configuration; used to verify the X-Hub-Signature-256 HMAC on every POST.
Both values are stored as a JSON-packed pair on the existing webhook secret field. No schema migration is required.See Incoming Webhooks for the full setup walk-through.

​
Documents in process instances

Each process instance now exposes a dedicated Documents tab. A single source of truth for every document handled during the process, regardless of how it entered the instance. Operations teams can review tracking metadata, preview, and download attached files from one place rather than walking through the process timeline.All Deployments
  • All document sources in one place. End-user uploads via the file-upload component, attachments from email triggers, files generated from HTML templates, OCR output, and files produced by AI workflow nodes, all listed under one tab.
  • Tracking metadata and preview. Each row shows source, timestamp, and uploader, with inline preview for supported file types.
  • Direct download. Download any attached document directly from the Documents tab.
  • Faster operations review. No more clicking through the process timeline to reconstruct which file came in at which step.

​
Two-stage attachment filtering for Email triggers

Email triggers (IMAP and Microsoft Outlook) now expose a two-stage filter on each trigger: choose which incoming emails create a process instance, then choose which attachments are forwarded into the process. The previous single on/off validations toggle is replaced with explicit, per-trigger control over inbound mail.All Deployments
  • Start Process for. Trigger the process for all emails, only emails with attachments, or only emails carrying selected file types (PDF, DOCUMENT, IMAGE, EXCEL, ZIP).
  • Save email attachments on process. Forward all attachments, none (metadata-only), or only specific file types into the process instance.
  • Trigger-level rejection. Emails that fail the trigger condition or exceed Maximum File Count are rejected with explicit Failed Triggers causes. No attachments, No matching file types, File count exceeded.
  • Backward-compatible upgrade. Existing triggers are migrated to All incoming emails + All attachments with no manual intervention. Reopen each trigger to reapply file-type filtering if you previously relied on the validations toggle.

​
Resume a process from an incoming webhook

Incoming Webhooks can now drive a Message Catch Intermediate Event, not just a Message Start Event. When a process is paused on an intermediate catch event, an external system can POST to the webhook to resume that specific instance. Useful for callbacks from third-party services, asynchronous job completions, or operator actions delivered over HTTP.All Deployments
  • Start or resume from one webhook model. The same webhook data source can start new processes (on a Message Start Event) or resume waiting ones (on a Message Catch Intermediate Event). The trigger type is set automatically based on where the webhook is attached.
  • Process Correlation Key. Each intermediate catch event declares a Process Correlation Key (a business variable like applicationId). The webhook-gateway matches this value against the incoming payload to route the resume to the right process instance. The Webhook Correlation Key now accepts array indices in square brackets (entry[0].changes[0].value.messages[0].text.body), so the canonical Meta WhatsApp resume path works without flattening upstream.
  • Validation at design time. Process Correlation Key and Process Key are required on intermediate webhook catch events and are validated when the message event is created or updated.
  • Backward-compatible upgrade. Existing webhooks are migrated to triggerType=START_PROCESS with no manual intervention. New webhooks attached to an intermediate catch event are flagged RESUME_PROCESS automatically.

​
REST endpoints: content-type-aware responses

REST endpoint responses in Integration Designer are now parsed by content type rather than assumed to be JSON. The endpoint’s Accept header drives parsing: JSON, plain text, and XML responses are each handled with the right parser, and the original XML string is preserved alongside the parsed map so downstream nodes can read either form. Existing JSON-returning endpoints continue to work without configuration changes.All Deployments
  • Accept-driven response parsing. The endpoint’s Accept header decides how the response is parsed. JSON variants (application/json, application/hal+json, application/problem+json, any +json suffix) are parsed as JSON; text/* is returned as a string; XML variants (application/xml, text/xml, application/soap+xml, any +xml suffix) are parsed into a JSON-shaped map. When Accept is missing, the endpoint falls back to Content-Type, then to AUTO best-effort.
  • XML responses parsed into JSON-shaped objects. XML response bodies are auto-converted to maps so existing path expressions (response.body.someField) work without code changes. The original XML string is preserved on sourceBody for callers that need it raw.
  • Loud failures on declared mismatches. When an endpoint declares JSON or XML and the upstream returns a different category, or returns a body that fails to parse, the node fails with a precise error message (for example, Expected response content type "application/json" but received "text/plain"). The original body is preserved on rawBody.
  • Tolerant under AUTO and wildcards. Wildcard Accept values (*/*, application/*, text/*) and inferred categories (no Accept declared) fall back to the raw string instead of failing. Flaky or mislabelled upstreams don’t break the node.
  • XXE-safe XML parser. XML parsing has DTD processing and external-entity resolution disabled by construction. External-entity attack payloads are neutralized; billion-laughs / entity-expansion attacks cannot fire.
  • File downloads bypass Content-Type checks. File-download endpoints (BINARY or BASE64) deliver the platform’s own JSON payload regardless of upstream Content-Type, so legacy PDF, octet-stream, and image downloads work unchanged.
  • Large XML returned raw. XML response bodies larger than 5 MiB are returned as the raw string instead of a parsed map, so very large payloads don’t block the node.
Mixed-content XML responses expose a new value key. An XML element with both attributes and inner text (<leaf attr="v">text</leaf>) is now parsed to {attr: "v", value: "text"}. The inner text used to be silently dropped. Downstream nodes that iterate response keys or assert the exact key set on mixed-content elements may see an additional value entry. Path expressions that addressed attributes or child elements directly are unaffected.

​
Raw endpoint payload type

REST endpoint configuration adds a Raw content type alongside JSON, Multipart, and Binary. Raw bodies are sent to the upstream system as-is. Useful for XML, SOAP envelopes, form-urlencoded payloads, or any plain-text body where you need to set the Content-Type header yourself.Before 5.9.0, the only way to send a non-JSON textual body was to use Multipart, which wrapped the payload in multipart/form-data and overrode the Content-Type header. Raw removes that wrapping.All Deployments
  • Body sent as-is. The body field is sent verbatim. The dispatcher does not transform, wrap, or pretty-print it.
  • Caller controls Content-Type. Set the Content-Type header on the endpoint to whatever the upstream expects (text/xml, application/soap+xml, application/x-www-form-urlencoded, text/plain). The dispatcher does not override it.
  • Monaco plain-text mode. The endpoint editor switches Monaco to plain text when Raw is selected. XML and SOAP indentation are preserved on paste and edit instead of being reformatted as JSON.
  • Shares the JSON body slot. Raw and JSON payloads use the same storage field on the endpoint definition, so no schema migration is required. Existing endpoints continue to work without changes.

​
Update Process Variables

JSON editor for variables on active instances with snapshot history; Compare diff.All Deployments

Documentation

Open the Update Process Variables documentation.

​
Stop Run for workflows

Cancel a running workflow instance from the editor.All Deployments

Documentation

Open the Stop Run for workflows documentation.

​
Notification history + template usages

/api/notification/summary and /api/notification/{id} endpoints; Usages modal lists all processes/workflows referencing a template.All Deployments

Documentation

Open the Notification history + template usages documentation.

​
Token view improvements

Horizontal scroll, frozen UUID and Status columns, hierarchical nesting, Context column, Initiator Node, color-coded status.All Deployments

Documentation

Open the Token view improvements documentation.

​
Stop workflow instances in runtime

Authorized end users can now stop running workflow instances directly from runtime. Previously, stopping a workflow required Designer access or a direct API call. The new control surfaces the action inside the runtime application alongside other workflow-instance management options.All Deployments
  • One-click stop. Stop a running workflow instance from the runtime instance list.
  • Permission-gated. The stop control is governed by runtime authorization.
  • Audited. Stop actions are recorded on the workflow-instance audit log with the actor and timestamp.

​
Native script engine for JavaScript and Python

The default script engine for JavaScript and Python business rules and workflow scripts moves from GraalVM polyglot contexts to a native subprocess pool. Scripts run in long-running Node.js and Python worker processes managed by process-engine and integration-designer. Existing scripts that read from input and write to output keep working, including output.put(...), output.get(...), and bracket assignment.The change is opt-out: set APPLICATION_SCRIPTENGINE_PROVIDER=graalvm on both services to keep the previous engine.Self-HostedAll Deployments
  • Node.js workers for JavaScript. JavaScript runs in isolated Node.js worker processes. Each script executes in a fresh V8 context with an explicit globals allowlist and a V8-level execution timeout.
  • CPython workers for Python. Python 3 runs in isolated worker processes with a curated sandbox. Common standard-library modules (random, math, datetime, re, hashlib, decimal, copy, string, collections, itertools, functools, uuid, base64) are available without import. Process, OS, and network modules are blocked.
  • Worker pools with recycling. Worker pools default to 16 Node.js workers and 8 Python workers, sized per service. Workers are recycled after a configurable number of executions to prevent state leakage.
  • HashMap method compatibility. The familiar output.put(key, value), output.get(key), and output.containsKey(key) methods continue to work on both JavaScript and Python. The same scripts that ran under GraalVM polyglot context keep working without rewrites.
  • GraalVM still available as opt-in. Set APPLICATION_SCRIPTENGINE_PROVIDER=graalvm on process-engine and integration-designer to keep the GraalVM engine, useful if a script depends on GraalVM-specific polyglot features.
  • Hardened execution sandbox. Per-execution fresh scope, environment variables cleared at worker startup, dangerous Python module references scrubbed before user code runs, no require / process / global access in JavaScript.
The native engine is the default on process-engine and integration-designer. Tune worker pools and timeouts as needed:
Environment VariableDescriptionDefault
APPLICATION_SCRIPTENGINE_PROVIDERScript engine provider. native or graalvm.native
APPLICATION_SCRIPTENGINE_NATIVEENGINE_JS_POOLSIZENode.js worker pool size.16
APPLICATION_SCRIPTENGINE_NATIVEENGINE_JS_EXECUTIONTIMEOUTMSJS execution timeout per script (ms).5000
APPLICATION_SCRIPTENGINE_NATIVEENGINE_PYTHON_POOLSIZEPython worker pool size.8
APPLICATION_SCRIPTENGINE_NATIVEENGINE_PYTHON_EXECUTIONTIMEOUTMSPython execution timeout per script (ms).10000
See Process engine setup → Script engine configuration and Integration Designer setup → Script engine configuration for the full set including payload size and worker recycling.
For most existing scripts the change is transparent. The input, output, additionalData, and instanceMetadata bindings behave the same, and HashMap-style access on output is preserved.Scripts that need attention:
  • Python scripts that import modules outside the curated allowlist. Narrow the script to use only the pre-loaded modules, or stay on GraalVM via the opt-out env var.
  • JavaScript scripts that reach for require(...), process, or global. Those references were never part of the supported surface area but may have worked under GraalVM. Rewrite to use only the bindings provided, or stay on GraalVM via the opt-out env var.
  • Scripts that depended on GraalVM-specific polyglot APIs (calling Java classes from JavaScript / Python). Stay on GraalVM via the opt-out env var.
See Script runtime change for JavaScript and Python business rules in the 5.1 → 5.9 migration guide for the full audit checklist.

​
Single-org self-hosted deployment

Self-hosted default mode. Guided setup wizard; explicit Designer / Runtime URL env vars.Self-Hosted

Documentation

Open the Single-org self-hosted deployment documentation.

​
License service

Centralized license validation and usage reporting for self-hosted deployments. License billing guards.Self-Hosted

Documentation

Open the License service documentation.

​
Authentication: opaque-token → JWT

Breaking change: SECURITY_TYPE default moves to jwt-public-key across all backend services; opaque-token introspection removed. Dedicated service-accounts realm; standardized flowx-{service}-sa client naming.All Deployments

Documentation

Open the Authentication: opaque-token → JWT documentation.

​
New services to deploy

webhook-gateway, email-gateway, license, organization-manager. Helm charts and infrastructure must be provisioned before upgrading.All Deployments

Documentation

Open the New services to deploy documentation.

​
Ingress routing and CORS handling

The NGINX ingress controller is deprecated as the FlowX-shipped default; the chart now supports Gateway API HTTPRoutes alongside Kubernetes Ingress with any controller. CORS handling moves from ingress annotations to the APPLICATION_CORS_ALLOWORIGIN environment variable on each backend service.All Deployments

Documentation

Open the Ingress routing and CORS handling documentation.

​
Kafka configuration alignment

Standardized KAFKA_BOOTSTRAP_SERVERS / KAFKA_SECURITY_PROTOCOL env vars with SPRING_KAFKA_* fallback. Mandatory Fx-Organization-Id header.All Deployments

Documentation

Open the Kafka configuration alignment documentation.

​
OpenTelemetry + SpiceDB DR

OpenTelemetry / Prometheus Helm charts published to Harbor; documented SpiceDB backup and disaster-recovery procedures.All Deployments

​
Task management localization

51 substitution tags + automatic table grid localization (300+ keys) across 30 languages.All Deployments

Documentation

Open the Task management localization documentation.

​
React Native SDK

FlowX 5.9.0 ships a brand-new React Native SDK, bringing the same process renderer model that has powered the React, Angular, iOS, and Android SDKs to React Native apps. Teams building cross-platform mobile or embedded React Native experiences can now host FlowX processes natively, with forms, navigation, and CMS integration handled by the SDK.A companion demo app is included as a reference integration, covering authentication, the showcase page, and the wiring needed to start a process from inside a container app.All Deployments
  • Process renderer. Render FlowX processes inside any React Native screen with the same component model as the other SDKs.
  • Forms and basic components. Page, Button, Text, Container, Card, and form components ship out of the box.
  • CMS integration. Static content and theming load from the FlowX CMS, including dynamic display values.
  • Navigation. Basic process navigation between screens follows the same patterns as the iOS and Android SDKs.
  • Demo app included. A demo app with authentication and a showcase page is shipped alongside the SDK as a reference integration.

​
iOS UI Flows support

The iOS renderer reaches feature parity with the React and Angular renderers on UI Flows. iOS apps can now start UI Flows from container apps, manage UI Flow sessions, dismiss modals, handle UI actions, and render document-plugin subtypes (images and document previews).All Deployments
  • Start UI Flow from container app. Container apps can launch a UI Flow with start parameters and handle the response.
  • UI Flow session management. The renderer manages a UI Flow session lifecycle on iOS the same way it does on web.
  • onLoad UI Event for Page. Pages emit an onLoad UI Event that iOS handlers can listen to, matching the cross-platform event model.
  • Dismiss action and dismiss-on-completion. A dismiss action type cleanly closes modals; dismiss on completion on START_WORKFLOW actions auto-closes the launching modal when the workflow finishes.
  • UI Flow start params. Pass typed start parameters into a UI Flow at launch.
  • Upload File support. UI Flows on iOS support file upload, including image and document-preview document-plugin subtypes.
  • Updated start-process endpoint. The iOS renderer uses the latest start-process endpoint and data property on Start UI Flow, aligned with the web SDKs.
  • New native components. Tooltip, Separator, Progress View, and Markdown components are now rendered natively on iOS, bringing the iOS component set closer to parity with the React and Angular renderers.
  • Accessibility properties from UI Designer. Accessibility properties configured in the UI Designer flow through to the iOS renderer, so screen reader labels and traits are honored on native screens.

​
React 19 upgrade

The React SDK upgrades to React 19, picking up the runtime improvements and APIs that ship with that release. Surrounding @flowx/* packages are upgraded in lockstep so the renderer continues to work as a single coherent bundle.Host apps embedding the React renderer should plan a React 19 upgrade on their side and run the standard React migration checks before adopting 5.9.0.All Deployments
  • React 19 runtime. Adopts the React 19 reconciler and the APIs that ship with that release.
  • Packages upgraded in lockstep. All @flowx/* web SDK packages move to the same baseline so the renderer ships as one coherent bundle.
Host apps that embed the React renderer must be on React 19 themselves. Run the React 19 codemods and verify any third-party React libraries you depend on are compatible before upgrading FlowX.

​
Runtime authorization and sharing

This is the biggest governance change in the 5.1 → 5.9 upgrade. End-user identities, runtime roles, and sharing assignments move out of Keycloak into FlowX-managed records, with project-version-scoped roles and a dedicated Share modal flow on Solutions.

Runtime authorization completion

Closes the rewrite: per-environment sharing checklist, project-level end-user roles, data-sync Keycloak provisioning. See the 5.9.0 card above.

Anonymous runtime access

Built-in Anonymous role + Share modal “Everyone with the link” option for unauthenticated end users. Session-bound (X-Fx-Anonymous-Session-Id), fire-and-forget; per-component hide/disable rules; SDK auth-skip mode.

Runtime authorization overhaul

Project-version-scoped roles, end-user groups in FlowX (moved from Keycloak), Solutions → Share modal, Active Policy gate, designer-user bypass, swimlane roles.

UI Flow permissions

Per-UI-Flow role allow-list with runtime 403 enforcement, per-component hide/disable, and assignments that travel with import/export.

End-user access management

Org-level End-Users, End-User Roles, End-User Groups separate from Designer users; CSV bulk invite.

Operations-editor role

New Workspace operations editor predefined role and wks_process_instance_variables_edit permission for ops teams to migrate tokens and edit variables.

Cross-workspace projects

Import the same project (UUID) into multiple workspaces in the same environment for UAT / Staging emulation.

​
Conversational AI

5.9 takes FlowX from no chat to production conversational AI: the Chat component, conversational workflows with memory and intent classification, voice and speech-to-text, chat-based UI Flows, and runtime controls.

Chat component

Standalone chat tab in web container apps with AI agent integration and session persistence. Inline / Floating / FullScreen display modes + iOS and Android mobile support. Chat History and Suggested Prompts. Markdown rendering.

Conversational Workflows

Chat Driven workflow type, multi-turn dialogue, Chat Session ID + User Message Start node, direct chat reply.

Voice input + Speech-to-Text

Audio recording, preview, and send within chat; Speech-to-Text node for transcription.

Memory capabilities

Built-in session memory: last 3 turns of the conversation, with a Use Memory toggle on the Custom Agent.

Intent Classification node

Dedicated node combining LLM classification + branching, up to 10 intents, If-No-Intent-Matches fallback.

Chat-based UI Flows

UI Flows expose a Flow-Based vs Chat-Based experience type set at the UI Flow level.

AI Triggers

Named parameterized message templates to launch conversational workflows with context.

Stop agent response

Stop button replaces Send while streaming; cancels the underlying workflow and persists a cancelled flag.

​
AI Agents and Knowledge

The agent-builder story: Custom Agents, MCP integration, Knowledge Bases for RAG, document and web extraction, AI Providers self-service, and PII Guard.

Evaluations (Evals)

Score AI node outputs against test cases with 10 built-in evaluators (LLM-as-judge: correctness, conciseness, hallucination, answer-relevance; RAG: groundedness, helpfulness, retrieval-relevance; code: exact-match, Levenshtein, JSON-match). Datasets attached to AI nodes, async judge pipeline via the new evals-judge service + 3 Kafka topics, per-org judge model via the new EVAL capability (default gpt-5.4-mini).

Custom Agent nodes

AI agents that use MCP tools to act autonomously inside workflows.

MCP integration

MCP servers as data sources; tools available in Custom Agent nodes; OAuth 2.0 SA auth, with BEARER/BASIC. 5.9.0 adds runtime config-param references (${yourParamName}) inside MCP server configuration fields for environment portability.

Knowledge Bases

Centralized KBs with PDF upload, workflow ingestion (Append / Replace / Delete), semantic search, and Custom Agent integration. Stores rename + typed filter builder; system metadata + Kafka indexer/embedder + Qdrant delete + FILE_PATH ingestion. 5.9.0 adds tunable Qdrant prefetch and fusion limits for hybrid search — deployment-time settings, covered in the deployment guidelines.

AI Providers self-service

Org-level OpenAI (BYOK / FlowX-Managed) and Azure OpenAI; Defaults & Fallbacks per capability + workspace type; Audio capability.

PII Guard

Per-AI-node guardrail with Strict / Balanced / Relaxed presets, input/output scans, file redaction. 5.9.0 adds per-entity detections on documents and images. See the 5.9.0 card above.

Extract Data from File

LLM / OCR / Text Parsing strategies; image input (JPG, PNG, TIFF); signature detection.

Web Page Extractor / Web Crawler

Crawl web pages, static or dynamic URLs, link-following depth, PDF extraction. URL filtering and file downloads; multi-URL filters.

Context Retrieval

RAG search against KBs without an LLM; hybrid / semantic / keyword; metadata filters and re-ranking. 5.9.0 surfaces per-chunk relevance scores in the node output so downstream nodes can branch or filter on confidence.

AI Developer generates Custom Components

Pre-built agent drafts React Custom Components (JSX, CSS, package.json, sample data) from a brief.

​
UI Flows and Custom Components

Build user-facing apps without a process. UI Flows reach feature parity with processes; Custom Components let teams ship React code inside the Designer.

UI Flows

Reusable multi-platform UI (web / iOS / Android) as project resources. Navigation Areas, Start Process / Navigate UI actions, Task Manager component. Breadcrumbs + Sessions monitoring. Process Renderer + Start Workflow action + On Load event. Route management + Start Parameters + Session Variables + onClick / On Display events. UI Flow permissions.

Custom Components

Write React JSX / CSS in the Designer. React, Emotion, Lodash, Axios, date-fns supported. Input keys + actions, import / export. Custom Components in Processes (with INPUT/OUTPUT mappings).

Process Renderer in UI Flows

Embed process renderers inside UI Flows.

UI Flow sessions monitoring

Runtime view with session list, audit log, process tracking, workflow debugging.

Accessibility (WCAG 2.1 AA)

Accessibility section in the UI Designer with ARIA, keyboard navigation, screen reader support across web / iOS / Android. Mobile accessibility expanded.

New theme components

Tooltip, Markdown, Progress Bar, Separator components across React / Angular / Android.

Multi-file bulk upload

Multiple File Upload component on process screens and UI Flows. Angular and React SDK support; single bulk endpoint + one SSE completion event.

Card default collapse + Tables in Collections

Cards configurable to load collapsed; Table UI components inside Collection prototypes.

​
Integration and Data Platform

For builders connecting FlowX to enterprise systems, 5.9 adds new data sources, new triggers, parallel workflow execution, REST resilience, and visual query authoring.

Email Trigger

New data source: IMAP-triggered processes, attachments routed to the document-plugin, validation rules, Manage Triggers UI. Resource management, reply-to, and mock-email testing.

Microsoft Outlook data source

Microsoft Graph integration via Azure AD; Read / Send / Read&Send scopes; conversation threads.

Incoming Webhooks

New webhook-gateway microservice; trigger processes via HTTP POST with API key auth. Provider adapters for Slack (HMAC-SHA256 + timestamp skew) and Meta (verify-token handshake + X-Hub-Signature-256). 5.9.0 adds Resume Process from intermediate catch events and the Meta provider. See the 5.9.0 cards above.

Oracle Database integration

Oracle 21c / 23ai data source; schema-aware Monaco editor; SERVICE_NAME or SID; SSL.

Unmanaged MongoDB data source

Connect to externally managed MongoDB 6.0+ instances with the same CRUD as the FlowX DB. 5.9.0 adds a visual query builder for Unmanaged Mongo (filter / projection / sort, generated-query preview, in-place result preview).

Send Notification action + Email Sender

SMTP data source and a new action that sends or replies email directly without going through Kafka.

Advanced Query Builder

Visual query builder replacing manual JSON. New operators (exists, contains, before, after, etc.).

Parallel branches in workflows

Start / End Parallel nodes for concurrent execution in Integration Designer.

REST endpoint caching + workflow partitioning

TTL-based caching for REST GETs (Expires After / Expires At); time-based workflow partitions (DAY / WEEK / MONTH) with retention.

Data mappers + workflow data models

Workflow data models with input / output; process ↔ workflow mapping; CRUD endpoints.

Proxy Server Connections

Reusable HTTP/HTTPS proxies attached to REST data sources.

Faster authoring loop

5.9.0 adds inline test modals on Script nodes and per-subworkflow individual runs. Iterate on script code or run a single subworkflow node without leaving the canvas.

​
Process operations

Day-2 operations for runtime teams: edit live process state, inspect tokens with more context, audit notifications, and operate on workflow instances.

Update Process Variables

JSON editor for variables on active instances with snapshot history; Compare diff.

Stop Run for workflows

Cancel a running workflow instance from the editor.

Notification history + template usages

/api/notification/summary and /api/notification/{id} endpoints; Usages modal lists all processes/workflows referencing a template.

Token view improvements

Horizontal scroll, frozen UUID and Status columns, hierarchical nesting, Context column, Initiator Node, color-coded status.
5.9.0 adds Stop workflow instances in runtime and Documents in process instances. See the 5.9.0 cards above.

​
Platform, deployment and infrastructure

Read this first if you operate a self-hosted deployment. 5.9 adds new microservices, a new deployment mode, and the auth architecture transition.

Single-org self-hosted deployment

Self-hosted default mode. Guided setup wizard; explicit Designer / Runtime URL env vars.

License service

Centralized license validation and usage reporting for self-hosted deployments. License billing guards.

Authentication: opaque-token → JWT

Breaking change: SECURITY_TYPE default moves to jwt-public-key across all backend services; opaque-token introspection removed. Dedicated service-accounts realm; standardized flowx-{service}-sa client naming.

New services to deploy

webhook-gateway, email-gateway, license, organization-manager. Helm charts and infrastructure must be provisioned before upgrading.

Native script engine for JavaScript and Python

JavaScript and Python business rules and workflow scripts run on a Node.js + CPython subprocess pool by default. HashMap-style access on output is preserved; GraalVM remains available via APPLICATION_SCRIPTENGINE_PROVIDER=graalvm. See the 5.9.0 card above and the migration audit checklist.

Ingress routing and CORS handling

The NGINX ingress controller is deprecated as the FlowX-shipped default; the chart now supports Gateway API HTTPRoutes alongside Kubernetes Ingress with any controller. CORS handling moves from ingress annotations to the APPLICATION_CORS_ALLOWORIGIN environment variable on each backend service.

Kafka configuration alignment

Standardized KAFKA_BOOTSTRAP_SERVERS / KAFKA_SECURITY_PROTOCOL env vars with SPRING_KAFKA_* fallback. Mandatory Fx-Organization-Id header.

OpenTelemetry + SpiceDB DR

OpenTelemetry / Prometheus Helm charts published to Harbor; documented SpiceDB backup and disaster-recovery procedures.

Task management localization

51 substitution tags + automatic table grid localization (300+ keys) across 30 languages.

​
Deployment notes

Deployment guidelines v5.9.0

Component versions, environment variables, Kafka topics, and self-hosted upgrade guidance.

Migrating from 5.1 LTS

Consolidated 5.1 LTS → 5.9 LTS migration guide. Direct upgrade to 5.9.0.
Last modified on June 11, 2026