Configuration
A Configuration defines global variables that can be shared across Logic Blocks and Flows within a project. Configurations provide a centralized place to manage values that are used throughout your logic, such as thresholds, default values, or system settings.
The Problem: Scattered Hardcoded Values
In any business application, certain values are referenced repeatedly across different logic components. Consider a common scenario: your organization requires manager approval for any purchase order over $10,000. This threshold might be checked in:
- A Validation Block that prevents submission of unapproved high-value orders
- A Decision Table that routes orders to different approval workflows
- A Flow that sends notification emails for orders requiring approval
- Another Flow that generates reports on approval-required orders
Without centralized configuration, this $10,000 value would be hardcoded in each of these locations. This creates several problems:
- Maintenance Burden: When the threshold changes to $15,000, you must find and update every occurrence
- Inconsistency Risk: Missing one location creates bugs where different parts of the system use different values
- No Audit Trail: Changes to hardcoded values aren't tracked or versioned
- Environment Differences: Development, test, and production might need different values
The Solution: Centralized Configuration
Configurations solve these problems by providing a single source of truth. Define the value once in a Configuration, reference it anywhere in your logic, and update it in one place when requirements change. All Logic Blocks and Flows that reference the configuration automatically use the updated value.
Structure
A Configuration consists of:
| Component | Description |
|---|---|
| Name | Unique identifier for the configuration (e.g., "OrderSettings", "ApprovalThresholds") |
| Description | Documentation explaining what settings this configuration contains |
| Project | The Flowon Project this configuration belongs to |
| Variables | One or more named, typed global variables |
| Caching Strategy | How and when configuration values are cached for performance |
Configuration Variables
Each variable within a Configuration has:
| Property | Description |
|---|---|
| Variable Name | Unique identifier within the configuration (e.g., "ApprovalThreshold") |
| Type | Data type using the Dataverse type system. Configuration values support: String, Integer, Decimal, Float, Money, Boolean, and DateTime |
| Value | The current value assigned to the variable |
| Description | Documentation explaining what this variable represents and how it's used |
Variables in a Configuration use the same type system as all Logic Composer constructs. This ensures type safety - if you define a variable as Money, you can only use it where a Money value is expected. The designer prevents type mismatches at design time.
Caching Strategies
Reading configuration values from the database on every use would impact performance. Each configuration variable declares one of three caching strategies to optimize this:
| Strategy | How It Works | Cache Duration | Best For |
|---|---|---|---|
| Volatile | Always reads from the database; the value is never cached | None | Values that can change at any time and must always be current (e.g., exchange rates updated by an external process) |
| Ephemeral | Cached for a limited period defined by a Time To Live (TTL), then re-read from the database | TTL (in minutes) | Values that change occasionally and can tolerate a bounded staleness window (e.g., tax rates, approval thresholds) |
| Constant | Cached and treated as effectively unchanging | Indefinite | Values that never (or almost never) change (e.g., system limits, fixed reference data) |
Choosing the Right Strategy
-
Volatile: Use sparingly, as it reads from the database on every use. Reserve it for values that are updated externally and must be reflected immediately.
-
Ephemeral: A good middle ground. You set a Time To Live (in minutes); the value is served from cache until the TTL elapses, then the next read refreshes it. A 60-minute TTL means at most a 60-minute delay before a change takes effect.
-
Constant: For values that effectively never change. The value is cached and reused, avoiding repeated database reads entirely.
Try It Live
The left panel shows the OrderProcessingSettings variables - each with its type and current value. The right panel animates how each caching strategy behaves: watch the read path change from a DB hit every time (Volatile) → TTL-bounded caching with a miss/store/hit/expiry sequence (Ephemeral) → an indefinitely cached value (Constant).
Using Configuration Variables
Once defined, configuration variables can be referenced in:
- Formula expressions: Use the variable directly in calculations
- Decision Table conditions: Compare inputs against configuration thresholds
- Decision Tree branches: Use configuration values as branch criteria
- Validation expressions: Validate against configurable limits
- Flow steps: Reference configuration values in any step that accepts expressions
Example: Order Processing Configuration
Configuration: OrderProcessingSettings
Description: "Global settings for order processing, approval routing, and fulfillment"
Variables:
┌─────────────────────────┬─────────┬────────────┬─────────────────────────────────────────┐
│ Variable Name │ Type │ Value │ Description │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ ApprovalThreshold │ Money │ $10,000 │ Orders above this amount require │
│ │ │ │ manager approval │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ MaxOrderAmount │ Money │ $100,000 │ Maximum allowed order amount │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ DefaultShippingDays │ Integer │ 5 │ Default number of business days for │
│ │ │ │ shipping estimates │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ ExpressShippingDays │ Integer │ 2 │ Shipping days for express delivery │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ TaxRate │ Decimal │ 0.08 │ Default tax rate (8%) │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ EnableExpressShipping │ Boolean │ true │ Feature flag: is express shipping │
│ │ │ │ currently available? │
├─────────────────────────┼─────────┼────────────┼─────────────────────────────────────────┤
│ ApprovalEmailTemplate │ String │ "order- │ Email template ID for approval │
│ │ │ approval" │ notifications │
└─────────────────────────┴─────────┴────────────┴─────────────────────────────────────────┘
Caching Strategy: Ephemeral
Time To Live: 60 minutes
Best Practices
Group Related Settings: Create separate configurations for different functional areas (OrderSettings, ApprovalSettings, NotificationSettings) rather than one massive configuration with everything.
Use Descriptive Names: Variable names should clearly indicate what they represent. "ApprovalThreshold" is better than "Threshold1" or "AT".
Document Everything: Add descriptions to both the configuration and each variable. Future maintainers (including yourself) will thank you.
Consider Cache Impact: When changing a cached configuration value, remember that the change won't take effect immediately across all users. For urgent changes, you may need to clear the cache or wait for expiration.
Use Appropriate Types: Don't store a monetary value as a String just because it's easier. Using the correct type (Money) ensures proper formatting, validation, and type safety.