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.

​

Types of configuration parameters

​

Value

• 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

• Use Cases:
  • Environment-specific API base URLs.
  • Dynamic configuration of services or integrations.
• Example:
  • Key: baseUrl
  • Type: environment variable
  • Value: BASE_URL (name convention pointing to an externally defined value)

​

Secret environment variable

• Use Cases:
  • Passwords or tokens for integrations.
  • Secure configuration of external services in the integration designer.
• Example:
  • Key: dbPassword
  • Type: secret environment variable
  • Value: DB_PASSWORD

​

Use cases for configuration parameters

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

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.
3. Click Save to include the parameter in the application build.

​

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.