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 Dynamics 365 type system (String, Integer, Decimal, Money, Boolean, DateTime, Entity Reference, Option Set) |
| 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 FlowOn Logic 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. FlowOn Logic provides caching strategies to optimize this:
| Strategy | How It Works | Cache Duration | Best For |
|---|---|---|---|
| No Cache | Always reads from database | None | Values that change frequently and must always be current (e.g., exchange rates updated by external process) |
| Session Cache | Cached per user session | Until session ends | User-specific settings that shouldn't change mid-session |
| Application Cache | Cached globally with expiration | Configurable (minutes/hours) | Stable values that rarely change (e.g., tax rates, approval thresholds) |
Choosing the Right Strategy
-
No Cache: Use sparingly, as it impacts performance. Only for values that are updated externally and must be immediately reflected.
-
Session Cache: Good for settings that might differ by user context or that could reasonably change between user sessions but should remain consistent within a single session.
-
Application Cache: The most common choice. Most configuration values (thresholds, defaults, system settings) change infrequently. A 1-hour cache means at most a 1-hour delay before changes take effect, which is acceptable for most business settings.
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: Application Cache
Cache Expiration: 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.