Configuration Parameters are defined per project version or library version, ensuring consistency across builds while allowing for environment-specific overrides. These parameters can be used across various components, such as business rules, UI elements, integration designer, and gateways.Libraries can define configuration parameters to facilitate testing of processes or workflows that depend on them. However, unlike project-level configuration parameters, libraries do not support direct overrides.
- Libraries provide default values for configuration parameters.
- Projects using these libraries can override the provided values as required.

Default and override values
- Default Value: Defined during parameter creation and included in the application build. It serves as the fallback value when no environment-specific override is set.
- Override Value: A value defined post-deployment for a specific environment. Overrides take precedence during runtime.
- Precedence Behavior (process variables override):
- If a process variable and a configuration parameter share the same name, the process variableβs value takes precedence during runtime.
- If the process variable is null or undefined, the configuration parameterβs value is used as a fallback.
- Process variables override configuration parameters unless the process variable is
null
or undefined, in which case the configuration parameter is used.
- Subprocess Behavior:
- When a value is passed to a subprocess, the subprocess uses the resolved value (process variable or configuration parameter) from the parent process.
- If a new value is defined within the subprocess, it is appended back to the parent process.
To avoid conflicts, use distinct names for process variables and generic parameters whenever possible.
Exception in Business Rules:
In business rules, values are taken directly from the map of configuration parameters without applying the above fallback logic.
In business rules, values are taken directly from the map of configuration parameters without applying the above fallback logic.
Configuration Parameters Overrides
Types of configuration parameters
Configuration parameters are defined as key-value pairs and support the following types:Value
A static value directly used by the project. Suitable for settings that do not change across environments.-
Use Cases:
- Feature flags to toggle functionality (e.g., enabling/disabling insurance sales in a customer dashboard).
- Email addresses for notification recipients.
- Homebank redirect URLs for specific processes.
-
Example:
- Key:
officeEmail
- Type:
value
- Value:
officeEmail@office.com
- Key:

Environment variable
References an external variable set by the DevOps team. These variables are defined per environment and referenced using a name convention.-
Use Cases:
- Environment-specific API base URLs.
- Dynamic configuration of services or integrations.
-
Example:
- Key:
baseUrl
- Type:
environment variable
- Value:
FLOWX_CONFIGPARAM_BASE_URL
(name convention pointing to an externally defined value)
- Key:
By default, only environment variables that match the regex pattern
FLOWX_CONFIGPARAM_.*
can be read at runtime. Variables that donβt follow this naming convention will not be accessible, even if they are properly defined. See Runtime access patterns for more details.Key | Type | Value | Description |
---|---|---|---|
baseUrl | environment variable | FLOWX_CONFIGPARAM_BASE_URL | A reference to the base URL configured externally by DevOps. |
Environment | External Variable Name | Actual Value |
---|---|---|
Development | FLOWX_CONFIGPARAM_BASE_URL | https://dev.example.com/api |
QA | FLOWX_CONFIGPARAM_BASE_URL | https://qa.example.com/api |
Production | FLOWX_CONFIGPARAM_BASE_URL | https://api.example.com |
Secret environment variable
Used for sensitive data like passwords, API keys, or credentials. These values are securely managed by DevOps and referenced using a name convention.-
Use Cases:
- Passwords or tokens for integrations.
- Secure configuration of external services in the integration designer.
-
Example:
- Key:
dbPassword
- Type:
secret environment variable
- Value:
FLOWX_CONFIGPARAM_DB_PASSWORD
- Key:
Like environment variables, secret environment variables must also follow the regex pattern
FLOWX_CONFIGPARAM_.*
to be accessible at runtime. See Runtime access patterns for more details.Use cases for configuration parameters
Configuration parameters simplify the management of environment-specific or dynamic settings across multiple project components:- Business Rules:
- Define dynamic logic based on parameters such as feature toggles or environment-specific conditions.
- Access configuration parameters directly from the
additionalData.applicationConfiguration
map.
For more information on how to use configuration parameters in business rules, see Extracting values from configuration parameters.
- UI Elements:
- Configure content dynamically based on the environment (e.g., URLs for redirects, conditional features).
- Note: Ensure variables referenced in UI components (e.g., for dynamic content or URLs) are uniquely named to avoid unexpected overrides by process variables.
- Integration Designer:
- Reference the token parameter.


- Gateways:
- Dynamically manage routing and decision-making logic using environment-specific parameters.
Adding a configuration parameter
To add a new configuration parameter:- Navigate to Your Project β Configuration Parameters.
- Click New Parameter and provide the following:
- Key: Name of the parameter.
- Type: Select
value
,environment variable
, orsecret environment variable
. - Value:
- For
value
: Enter the static value. - For
environment variable
orsecret environment variable
: Enter the agreed name convention (must start withFLOWX_CONFIGPARAM_
by default).
- For
- Click Save to include the parameter in the application build.
Remember that environment variables and secret environment variables must follow the naming pattern
FLOWX_CONFIGPARAM_*
to be accessible at runtime. See Runtime access patterns for more details.
Runtime access patterns
FlowX.AI implements security controls to limit which environment variables and secrets can be accessed at runtime. This prevents unauthorized access to system variables and ensures only intended configuration parameters are readable by the application.Default regex pattern
By default, the FlowX Engine uses the regex patternFLOWX_CONFIGPARAM_.*
to filter which configuration parameters can be accessed at runtime. This means:
- Environment variables and secret environment variables must start with
FLOWX_CONFIGPARAM_
to be readable - Variables that donβt match this pattern will be ignored, even if properly defined in the environment
- This security measure prevents accidental access to system variables like
SPRING_*
,JAVA_*
, or other sensitive environment variables
Naming convention requirements
When defining environment variables or secret environment variables, follow this naming convention: β Correct naming:FLOWX_CONFIGPARAM_API_URL
FLOWX_CONFIGPARAM_DB_PASSWORD
FLOWX_CONFIGPARAM_EXTERNAL_SERVICE_TOKEN
API_URL
DB_PASSWORD
SERVICE_TOKEN

Customizing the regex pattern
The default regex pattern can be overridden by configuring the following environment variables on the FlowX Engine:Environment Variable | Description | Default Value |
---|---|---|
FLOWX_CONFIGPARAMS_VARS_ALLOWLISTREGEX | Regex pattern for environment variables | FLOWX_CONFIGPARAM_.* |
FLOWX_CONFIGPARAMS_SECRETS_ALLOWLISTREGEX | Regex pattern for secret variables | FLOWX_CONFIGPARAM_.* |
Changing the default regex pattern should be done carefully and only by experienced DevOps teams. Using overly permissive patterns (like
.*
) can expose sensitive system variables to the application.Best practices for naming
- Always use the prefix: Start all environment and secret variables with
FLOWX_CONFIGPARAM_
- Use descriptive names: Make variable names clear and specific to their purpose
- Follow consistent naming: Use uppercase with underscores for environment variables
- Test accessibility: Verify that your variables are accessible in your target environment before deployment
Technical notes and best practices
Security
- Sensitive Values (ENV_SECRET):
- Store and manage securely.
- Do not display in the frontend or expose via public APIs.
- Avoid logging sensitive information.
Environment-specific updates
- Environment variable updates (
ENV
/ENV_SECRET
) are managed by DevOps. - Updates may require service restarts unless a caching or real-time mechanism (e.g., change streams) is implemented.
Reserved keys
- Certain keys are reserved for system use (e.g.,
processInstanceId
). Avoid using reserved keys for custom configurations.
Variable naming
- Avoid Shared Names:
- Do not use the same name for configuration parameters and process variables to prevent unintentional overrides.
- Fallback Logic Awareness:
- Understand that
null
orundefined
process variables will default to the corresponding configuration parameterβs value during runtime.
- Understand that
- Subprocess Behavior:
- Variables in subprocesses are appended back to parent processes with their current state. Plan naming conventions and data flows accordingly.
When designing processes, ensure that variables in subprocesses and parent processes do not conflict with configuration parameters names. Test these interactions in scenarios where variables are dynamically assigned or left undefined.