CIC Studio - Getting Started with Application Preferences: Create Configurable Solutions

[Valerio_Provaggi]

Why Application Preferences?

Through customer feedback and our experience with low-code solutions, we identified a recurring need for greater configurability at the application level. Solution builders often need to adjust how a solution behaves after it has been deployed.

Application Preferences introduce configuration points that can be managed independently from the solution design. They allow builders to:

• Centralize and reuse configuration instead of duplicating values across processes.
• Define values that can be changed while the solution is running, without requiring a new application version for every configuration update.

This makes Application Preferences useful both for configuring solution behavior and for managing shared values consistently across an application.

Differences with Environment variables

• Environment variables act as placeholders for values that are valid across an entire environment. The primary difference between environment variables and Application Preferences is their scope: environment variables apply at the environment level, while Application Preferences apply at the application level.
• The second key difference lies in the type and flexibility of the values they support. Application Preferences use structured key–value pairs to represent configuration and can support richer formats, such as objects and arrays, making them suitable for more complex configurations.

Create Application Preferences

Application Preferences are Studio assets.

When creating an Application Preference, you provide the name and description, as you would for other assets. You also define an access key, which uniquely identifies the preference when it is referenced in Studio or retrieved through the API.

The access key uses camelCase and is generated automatically from the preference name. You can modify the generated key if needed.

Each Application Preference consists of a structure of key–value fields; when creating a field, you must provide a default value. The default values will be the ones used once the application is deployed.

 Five field types are supported:

• 3 simple : String, Number, Boolean
• 2 complex: Object, Array

Use Application Preferences

In input mappings, you can reference individual Application Preference fields using the following expression:

${applicationPreferences.preferenceName.fieldName}

For example:

${applicationPreferences.companySettings.supportEmail}

When the Runtime Engine encounters an Application Preference expression as a task input, it resolves the preference value at that point. To keep the value persistent throughout the process instance, assign it to a process variable so that it follows the variable’s lifecycle.

We are progressively adding support for auto-suggestions when entering these expressions.

Note: Application Preferences cannot be assigned as default values for process variables in the variable creation UI, use Set.

Some guidelines

1. When mapping an Application Preference as a task input, reference the specific field value you need. Do not pass the entire preference as JSON.
2. Do not store secrets or other sensitive information in Application Preferences.
3. Use Application Preferences as a centralized place to store values that are reused across different areas of a project. They provide shared configuration values; they are not global variables.

What's Next

We are working in two directions to make preference more valuable in the solution:

• Expand auto-suggestions to make Application Preferences easier to use in Studio.
• Introduce a dedicated, out-of-the-box UI for managing preferences at runtime.

Currently, runtime configuration is available through the Preference Service APIs documented in Swagger UI:

 <base_application_URL>/rb/swagger-ui/index.html?urls.primaryName=Preference