Environment Variables vs Configuration Tables vs Hardcoding in Dynamics 365 Customer Engagement (CE)

In Dynamics 365 Customer Engagement (CE), managing configuration values effectively is key to building scalable and maintainable solutions. Environment Variables are best suited for storing environment-specific data such as API URLs, keys, or connection strings, allowing smooth deployment across development, testing, and production environments without code changes. Configuration Tables, on the other hand, are ideal for storing frequently changing business settings—such as thresholds, flags, or parameters—that can be modified directly within the application by administrators or business users. In contrast, hardcoding values directly into plugins or scripts should be avoided except for fixed constants, as it reduces flexibility and makes maintenance difficult. By combining Environment Variables for system-level settings and Configuration Tables for business logic, developers and architects can create cleaner, more secure, and easily adaptable Dynamics 365 solutions.

1. Environment Variables

Environment Variables in Dynamics 365 CE (and the Power Platform) are a structured way to store configuration data that can vary between environments (like Development, UAT, and Production). They were introduced to make solution management, deployment, and environment-specific configuration easier.

Key Characteristics

Defined as part of a solution (managed or unmanaged).

Values can differ per environment, even though the variable name remains the same.

Can store information like API URLs, keys, or feature flags.

Accessed through Power Automate, Power Apps, or custom code (plugins, JavaScript).

Typical Use Cases

Storing API endpoints or base URLs for external integrations.

Managing feature toggles (e.g., enabling or disabling functionality).

Defining email addresses, queue names, or connection strings used across environments.

Advantages

• Easily configurable per environment.
• Deployable through solutions — great for ALM (Application Lifecycle Management).
• Reduces risk of manual post-deployment updates.

Limitations

• Not ideal for storing large sets of data or frequently changing business parameters.
• Value retrieval in plugins requires additional code logic (e.g., using a helper utility class).

2. Configuration Table (Custom Configuration Entity)

A Configuration Table (or Configuration Entity) is a custom entity you create in Dynamics 365 to store system-wide or functional configuration settings. Unlike environment variables, configuration records are stored as data, not metadata.

Key Characteristics

• Used to manage dynamic, business-specific settings that may change often.
• Typically contains columns like Name, Value, Description, IsActive, etc.
• Easily maintained through the Model-Driven App interface by administrators.
• Accessible directly in plugins, Power Automate, or client scripts using standard Dataverse queries.

Typical Use Cases

• Storing threshold values, default business rules, or dynamic parameters.
• Managing integration credentials or tokens that may refresh periodically.
• Maintaining business rules or mappings (e.g., region → queue assignment).

Advantages

• Can be updated without deploying new solutions.
• Stores multiple configuration records with filtering and history tracking.
• Supports audit, security, and data-based logic.

Limitations

• Slightly slower access compared to environment variables due to data retrieval.
• Can become complex if not well-structured (naming and version control issues).

3. Hardcoding

Hardcoding refers to directly embedding static configuration values (like URLs, IDs, or strings) into the code — for example, inside a plugin, JavaScript, or workflow logic.

Key Characteristics

• The value is fixed in the code — changes require code updates and redeployment.
• Fastest execution since no data lookup is required.
• Commonly seen in older or quick prototype implementations.

Typical Use Cases

• Temporary testing or prototype environments.
• Very stable values that will never change (e.g., a constant prefix or system identifier).

Advantages

• Simple to implement.
• Fastest runtime performance.

Limitations

• Difficult to maintain — requires code re-deployment for any change.
• Inconsistent values across environments.
• Increases risk of errors during deployments.
• Violates best practices for configuration management.

Comparison Summary

• Best For: Solution-aware settings that vary across environments (e.g., Dev, Test, UAT, Prod).
• Examples: API URLs, Keys, Integration Endpoints, Environment-specific parameters.

Why Use:

• Managed and secure within the Power Platform solution.
• Automatically transferred between environments via solutions.
• Reduces manual configuration errors during deployment.
• Supported natively in Power Apps, Power Automate, and Plugins.

Architect Recommendation:

Use Environment Variables as the default configuration approach for most environment-dependent or deployment-sensitive parameters.

2. Configuration Tables (Advanced and Flexible)

• Best For: Dynamic data, business logic configurations, or frequently changing parameters that business users can manage.
• Examples: Threshold values, feature toggles, business rules, or mapping data.

Why Use:

• Easily updated through UI without redeploying solutions.
• Can store multiple settings or contextual configurations (e.g., per Business Unit).
• Supports auditing and version tracking.

Architect Recommendation:

Use Configuration Tables for business or functional parameters that may evolve frequently or need to be managed by non-technical users.

3. Hardcoding (Not Recommended)

Best For: Only constants that are unlikely to ever change, such as fixed enum values or standard status codes.

Why Avoid:

• Difficult to maintain or update across environments.
• Requires code changes and redeployment.
• Increases risk of errors during upgrades or integrations.

Architect Recommendation:

Avoid Hardcoding for environment- or business-dependent logic. Use it only for true constants that are part of application logic and not configuration.

Summary Recommendation

Architect Tip:

Combine both approaches where appropriate — use Environment Variables for environment-dependent values and Configuration Tables for dynamic, business-managed data. This balance ensures scalability, governance, and maintainability across environments.