Skip to main content

Configuration

Core service configuration

Service communication

Storage configuration

S3 storage for files in Integration Designer.

Redis

Integration Designer uses Redis for caching workflow execution data. Cache-specific configuration: Redis connection: Quick reference:
Both SPRING_DATA_REDIS_* and SPRING_REDIS_* variable prefixes are supported. The SPRING_DATA_REDIS_* prefix is the modern Spring Boot standard and is recommended for new deployments.
For advanced Redis deployment modes (Sentinel, Cluster) and SSL/TLS setup, see the Redis Configuration guide. Note that Sentinel and Cluster modes are only supported by the Events Gateway service.

WebClient configuration

Integration Designer interacts with various APIs, some of which return large responses. To handle such cases efficiently, the FlowX WebClient buffer size must be configured to accommodate larger payloads, especially when working with legacy APIs that do not support pagination.

Workflow execution configuration

AI service configuration

FLOWX_WORKFLOW_MAXEXECUTEDNODES is a safety guardrail — workflows that exceed this limit are terminated. Increase only if your workflows legitimately require more node executions.

Agent Builder configuration

Starting with 5.9.2, AI Platform services are deployed under their plain names — the ai-platform- prefix is dropped from the default hostnames. If you overrode these variables with the old prefixed names, update them when upgrading. See the 5.9.2 deployment guidelines.

Process Engine configuration

MCP client configuration

Timeouts for MCP (Model Context Protocol) server connections used by MCP Server data sources.

Async AI callback configuration

Controls how timed-out AI node callbacks are reaped.

Script engine configuration

Integration Designer uses a native script engine for executing JavaScript and Python scripts in workflow nodes. The native engine runs scripts in separate Node.js and Python worker processes.
The native script engine is the default starting with 5.9.0. It replaces the previous GraalVM-based engine and runs scripts in isolated Node.js / Python subprocess pools. If you need to revert to GraalVM, set APPLICATION_SCRIPTENGINE_PROVIDER=graalvm.

Knowledge Base RAG configuration

Oracle SQL schema discovery

Retry configuration

Database configuration

Advancing database

The Advancing Controller is a support service that optimizes advancing operations by ensuring efficient, balanced workload distribution—especially during scale-up and scale-down events. To enable Integration Designer to interact with the Advancing database, configure the following environment variables:
It can connect to the same database as the FlowX.AI Engine.

Configuring the Advancing controller

How the new advancing controller works:
  • Picking threads (ADVANCING_PICKINGTHREADS): Controls how many worker threads read events from the database. This handles only the picking/reading operations.
  • Processing buffer (ADVANCING_PROCESSINGBUFFERSIZE): Acts as a queue between picking and processing. When the buffer is full, no new events are read. When there’s available space (even just 1 position), that amount of events will be read.
  • Processing threads (ADVANCING_PROCESSINGTHREADS): Controls how many threads process the advancing events in parallel. Events are processed instantly if processing threads are available. If all processing threads are busy, events accumulate in the buffer until it reaches capacity.
The Advancing Controller supports multiple database systems including PostgreSQL and Oracle. Ensure you configure the appropriate JDBC URL and driver class for your chosen database system.

Workflow partitioning configuration

Workflow partitioning allows you to manage workflow instance data more efficiently by organizing data into time-based partitions. This is particularly useful for large-scale deployments where workflow instances accumulate over time.
DROP permanently deletes archived data. When FLOWX_DATA_PARTITIONING_ARCHIVING_POSTARCHIVE_ACTION is set to DROP, archived data older than POSTARCHIVE_RETENTIONDAYS is deleted with no soft-delete and no way to recover it. Keep the default KEEP in production unless you have an explicit data-retention or compliance sign-off, and set the same value on Integration Designer and the process-engine.
Set FLOWX_DATA_PARTITIONING_INTERVAL to the same value on Integration Designer and the process-engine. A mismatch desynchronizes archive alignment between the two services.
How workflow partitioning works:
  • Partitioning: When turned on, workflow instances are stored in time-based partitions according to the specified interval.
  • Partition interval: Determines how frequently new partitions are created (DAY, WEEK, or MONTH).
  • Archiving: When turned on, automatically archives partitions older than the specified retention intervals. For example, with MONTH interval and 3 retention intervals, partitions older than 3 months will be archived.
  • Archiving schedule: The cron expression controls when the archiving process runs. The default 0 0 1 * * ? runs daily at 1:00 AM.
Partitions that still contain unfinished workflow instances are not archived. The archiving job processes a partition only when every workflow instance in it has reached a finished state: FINISHED, FAILED, or CANCELLED. A single workflow instance still in STARTED blocks the entire partition; the partition is retried on the next archiving run. If archiving stalls, turn on the stuck-instance termination sweep (FLOWX_DATA_PARTITIONING_ARCHIVING_STUCKTERMINATE_ENABLED) to force blocking workflow instances into a final state so archiving can advance.
Turn on partitioning and archiving only after careful planning and testing. Once turned on, ensure that your database has sufficient storage for partition management operations. It’s recommended to start with archiving turned off and turn it on only after verifying that partitioning works correctly for your use case.

MongoDB

Integration Designer requires two MongoDB databases for managing integration-specific data and runtime data:
  • Integration Designer Database (integration-designer): Stores data specific to Integration Designer, such as integration configurations, metadata, and other operational data.
  • Shared Runtime Database (app-runtime): Shared across multiple services, this database manages runtime data essential for integration and data flow execution.
Integration Designer requires a runtime connection to function correctly. Starting the service without a configured and active runtime MongoDB connection is not supported.

Configuration parameters

There are two types of Config Params that can be read from the environment: variables and secrets. There is one provider for variables and secrets extracted from the environment variables, and two providers for the ones extracted from Kubernetes. By default, the variables and secrets are extracted from environment variables (env provider).

Configuration parameters from environment variables (default)

The env provider used for variables and secrets extracts them from environment variables. For security reasons, the env provider uses an allow list regex which defaults to FLOWX_CONFIGPARAM_.*. This means only environment variables that match this naming pattern can be read at runtime into configuration params (either as variables or secrets). Feel free to edit it to match the environment variables that you use in your deployment.

Configuration parameters from Kubernetes Secrets and ConfigMaps

Use the following configuration to read Config Params from Kubernetes Secrets and ConfigMaps: These providers can be configured as follows:
You can configure multiple secrets and ConfigMaps by incrementing the index number (e.g., FLOWX_CONFIGPARAMS_PROVIDERS_K8SSECRETS_SECRETSLIST_1, FLOWX_CONFIGPARAMS_PROVIDERS_K8SCONFIGMAPS_CONFIGMAPSLIST_1). In dev environments, the typical ConfigMap/Secret name is flowx-rt. Values are overridden based on the order in which the maps are defined.The default provider is env, but there is a built-in allowlist with the regex pattern FLOWX_CONFIGPARAM_.*. This means only configuration parameters that match this naming pattern can be read at runtime, whether they are environment variables or secret variables.

Kafka configuration

Kafka connection and security variables

Message size configuration

This setting affects:
  • Producer message max bytes
  • Producer max request size

Consumer configuration

Topic naming convention and pattern creation

The Integration Designer uses a structured topic naming convention that follows a standardized pattern, ensuring consistency across environments and making topics easily identifiable.
Topic naming components
Topics are constructed using the following pattern:
For example, a typical topic might look like:
Where:
  • ai.flowx. is the prefix (package + environment)
  • eventsgateway is the service
  • receive is the action
  • workflowinstances is the detail
  • .v1 is the suffix (version)

Kafka topic configuration

Core topics
Events gateway topics
UI flow session variable updates
When a workflow triggered by a UI Flow finishes, the integration-designer sends the result to the process-engine so the session variables are updated automatically.
Knowledge Base store entry lifecycle topics
These topics handle communication between Integration Designer and the AI Platform for Knowledge Base store entry indexing operations.
AI Platform job topics
Integration Designer dispatches document parsing, speech-to-text, and evaluation jobs to the AI Platform over Kafka. Each job family has a request topic (produced), a response topic (consumed), and a dead-letter topic (consumed).
Engine and Integration communication topics
Application topics
Outbound topics:
The sync.out.v1 and correction-after-app-operation.response.v1 topics exist since 5.1.x (produced by admin). Starting with 5.5.0, integration-designer also produces to these shared response topics for system and workflow sync/correction operations.
Inbound topics:

OAuth authentication variables (when using SASL_PLAINTEXT)

When using the kafka-auth profile, the security protocol will automatically be set to SASL_PLAINTEXT and the SASL mechanism will be set to OAUTHBEARER.

Inter-Service topic coordination

When configuring Kafka topics in the FlowX ecosystem, ensure proper coordination between services:
  1. Topic name matching: Output topics from one service must match the expected input topics of another service.
  2. Pattern consistency: The pattern values must be consistent across services:
    • Process Engine listens to topics matching: ai.flowx.engine.receive.*
    • Integration Designer listens to topics matching: ai.flowx.integration.receive.*
  3. Communication flow:
    • Other services write to topics matching the Engine’s pattern → Process Engine listens
    • Process Engine writes to topics matching the Integration Designer’s pattern → Integration Designer listens
The exact pattern value isn’t critical, but it must be identical across all connected services. Some deployments require manually creating Kafka topics in advance rather than dynamically. In these cases, all topic names must be explicitly defined and coordinated.

Kafka topics best practices

Large message handling for workflow instances topic

The workflow instances topic requires special configuration to handle large messages. By default, Kafka has message size limitations that may prevent Integration Designer from processing large workflow payloads. Recommended max.message.bytes value: 10485760 (10 MB)
  1. Access AKHQ
    • Open the AKHQ web interface
    • Log in if authentication is required
  2. Navigate to Topic
    • Go to the “Topics” section
    • Find the topic: ai.flowx.eventsgateway.receive.workflowinstances.v1
  3. Edit Configuration
    • Click on the topic name
    • Go to the “Configuration” tab
    • Locate or add max.message.bytes
    • Set the value to 10485760
    • Save changes

CAS lib configuration

CAS lib is used to communicate with the authorization-service through SpiceDB.

Configuring authentication and access roles

Integration Designer validates incoming tokens with the JWT public key mechanism and authenticates to other FlowX services with a dedicated service account (the mainIdentity client registration) in the service-accounts realm:
Upgrading from 5.1.x? Remove the legacy opaque-token env vars: SECURITY_OAUTH2_REALM, SECURITY_OAUTH2_CLIENT_CLIENTID, SECURITY_OAUTH2_CLIENT_CLIENTSECRET, and SECURITY_OAUTH2_SERVICEACCOUNT_ADMIN_*. These belong to the removed introspection model and prevent the service from starting on 5.9.x. See the authentication and IAM migration guide for the full list.
For detailed instructions on configuring user roles and access rights, refer to:

Access Management

For configuring a service account, refer to:

Integration Designer service account

Configuring logging

To control the log levels for Integration Designer, set the following environment variables:

Configuring admin ingress

The Integration Designer service uses the standard FlowX.AI ingress pattern. For complete setup instructions including the full ingress template, CORS configuration, and troubleshooting, see the Ingress Configuration Guide. Service-specific values for Integration Designer:
  • Ingress name: integration-designer-admin
  • Service path: /integration(/|$)(.*)
  • Service name: integration-designer
  • Rewrite target: /$2
  • Fx-Workspace-Id: Required

Complete Ingress Configuration

View the centralized ingress guide for the complete configuration template, annotations reference, and best practices.

Monitoring and maintenance

To monitor the performance and health of the Integration Designer, use tools like Prometheus or Grafana. Configure Prometheus metrics with:

RBAC configuration

Integration Designer requires specific RBAC (Role-Based Access Control) permissions to access Kubernetes ConfigMaps and Secrets, which store necessary configurations and credentials. Set up these permissions by enabling RBAC and defining the required rules:
This configuration grants read access (get, list, watch) to ConfigMaps, Secrets, and Pods, which is essential for retrieving application settings and credentials required by Integration Designer.

Ingress and CORS

The Integration Designer service is exposed externally on the admin host. Routing is configured through the FlowX Helm chart, which renders either a Kubernetes Ingress (default) or a Gateway API HTTPRoute per service. CORS handling lives in the service code; only the allowed-origins list is deployment-specific.

Service route

The path is set through services.integration-designer.ingress.admin.path (or services.integration-designer.gateway.admin.paths) in the chart values.

CORS configuration

Allowed methods, allowed headers (including Authorization, Content-Type, Fx-Workspace-Id), and credential handling are baked into the service’s application.yaml with safe defaults. Override these only if you have a non-standard requirement. For the complete route reference, Gateway API HTTPRoute configuration, and route customization, see the ingress configuration guide.

Troubleshooting

Common issues

Symptoms: Service crashes on startup or fails health checks.Solutions:
  1. Verify MongoDB connection URIs for both the integration-designer and app-runtime databases
  2. Check that Kafka broker addresses are reachable and the security protocol is correct
  3. Ensure the Keycloak service account is properly configured and the client secret is valid
  4. Review logs at LOGGING_LEVEL_APP=DEBUG for detailed startup error messages
Symptoms: Workflow executions fail at REST connector nodes with timeout or connection errors.Solutions:
  1. Verify network connectivity between the Integration Designer pod and the target system
  2. Check SSL/TLS certificates if the target system uses HTTPS
  3. Review timeout settings and increase FLOWX_WEBCLIENT_BUFFERSIZE if responses are large
  4. Ensure firewall rules and network policies allow outbound traffic to the target host and port
Symptoms: Workflows start but fail during execution with Kafka or data mapping errors.Solutions:
  1. Verify that all required Kafka topics exist and are correctly named across services
  2. Check that input/output parameter mappings match the expected data model
  3. Ensure the KAFKA_TOPIC_ENGINEPATTERN and KAFKA_TOPIC_INTEGRATIONPATTERN values are consistent with the Process Engine configuration
  4. Review the events gateway topic (KAFKA_TOPIC_EVENTSGATEWAY_OUT_MESSAGE) for message delivery issues
Symptoms: Data sources configured in Integration Designer show connection errors or timeouts.Solutions:
  1. Verify that the credentials for the target data source are correct and not expired
  2. Check network access between the Integration Designer pod and the data source endpoint
  3. Ensure firewall rules allow traffic on the required ports
  4. For S3-compatible storage issues, verify APPLICATION_FILESTORAGE_S3_SERVERURL and access key configuration

Integration Designer

Learn about the Integration Designer and how to build integration workflows

Building a Connector

Step-by-step guide for creating connectors in Integration Designer

Redis Configuration

Complete Redis setup including Sentinel and Cluster modes

Kafka Authentication

Configure Kafka security and authentication

IAM Configuration

Identity and access management setup

Events Gateway Setup

Configure the Events Gateway for inter-service communication
Last modified on July 16, 2026