Configuration parameters

---

​

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.

For details on configuring runtime overrides, see:

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

---

​

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)

Configuration details:

Key	Type	Value	Description
baseUrl	environment variable	FLOWX_CONFIGPARAM_BASE_URL	A reference to the base URL configured externally by DevOps.

Example values for different environments

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

---

​

Use cases for configuration parameters

Configuration parameters simplify the management of environment-specific or dynamic settings across multiple project components:

1. 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.

2. 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.
3. Integration Designer:
   • Reference the token parameter.

4. Gateways:
   • Dynamically manage routing and decision-making logic using environment-specific parameters.

​

Adding a configuration parameter

To add a new configuration parameter:

1. Navigate to Your Project → Configuration Parameters.
2. Click New Parameter and provide the following:
   • Key: Name of the parameter.
   • Type: Select value, environment variable, or secret environment variable.
   • Value:
     • For value: Enter the static value.
     • For environment variable or secret environment variable: Enter the agreed name convention (must start with FLOWX_CONFIGPARAM_ by default).
3. Click Save to include the parameter in the application build.

---

​

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 pattern FLOWX_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

❌ Incorrect naming (will not be accessible):

• 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_.*

​

Best practices for naming

1. Always use the prefix: Start all environment and secret variables with FLOWX_CONFIGPARAM_
2. Use descriptive names: Make variable names clear and specific to their purpose
3. Follow consistent naming: Use uppercase with underscores for environment variables
4. 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 or undefined process variables will default to the corresponding configuration parameter’s value during runtime.
• Subprocess Behavior:
  • Variables in subprocesses are appended back to parent processes with their current state. Plan naming conventions and data flows accordingly.

---