When you're building solutions in Dynamics 365 CE, how you manage configuration values can make a big difference. Things like URLs, toggles, credentials, and feature flags need to be stored somewhere—and choosing the right place to put them impacts maintainability, ALM, and performance.
Let’s walk through three common options:
- Environment Variables
- A custom Configuration Table (often called
msdyn_Configuration) - Hardcoding values directly into your code
Each approach has its strengths, limitations, and ideal use cases. Here’s how I think about them.
Environment Variables
Environment Variables are built into the Power Platform and are great for handling configuration values that change across environments—like API URLs or toggle flags.
They’re solution-aware, which means they move cleanly through Dev, Test, and Prod environments during deployment.
Pros
- Easy to use and maintain through the Power Apps UI
- Can be overridden per environment
- Great for static or rarely changing values
Cons
- Not ideal if values need to be updated frequently at runtime
- Can't store complex or relational data
- Not easily accessible to non-admin users
When to Use
Environment Variables are perfect for environment-specific values—things like connection strings, base URLs, or feature flags that stay relatively stable.
Configuration Table (e.g. msdyn_Configuration)
This is a custom table you create to store key-value pairs. Many projects use this to handle runtime configuration or flags that need to be updated by system admins or support teams.
It’s flexible, extensible, and works great when you need the ability to change values without touching a solution.
Pros
- Editable at runtime without deployments
- Can be used by anyone with appropriate permissions
- Easy to extend with metadata, tags, or audit tracking
Cons
- Not solution-aware by default—you have to manage it manually
- Requires a little setup and some plugin or script logic to read from it
- No built-in support for per-environment overrides
When to Use
Use a configuration table when values need to change at runtime or be editable by business users without requiring a deployment. This is common for thresholds, dynamic flags, or temporary toggles.
You can also build a small admin app for updating these configs.
Hardcoding Values
Hardcoding a value directly into a plugin, JavaScript, or flow might feel like the fastest route—especially during prototyping—but it comes with long-term risk.
Pros
- Simple and quick when you're just testing something
- No extra setup or structure needed
Cons
- Difficult to maintain or update later
- Doesn’t support ALM or environment-specific values
- Easy to forget or overlook when moving between environments
When to Use
Honestly, avoid hardcoding unless you’re in an early test phase or writing throwaway code. For anything long-term or shared across environments, stick to environment variables or configuration tables.
Summary Comparison
| Feature | Environment Variable | Configuration Table | Hardcoding |
|---|---|---|---|
| Works with ALM & solutions | Yes | No (manual) | No |
| Editable at runtime | No | Yes | No |
| Supports environment overrides | Yes | No | No |
| Easy for support/admins to update | No | Yes | No |
| Recommended for production use | Yes | Yes | No |
Final Thoughts
If you're building serious solutions in Dynamics CE, how you manage configuration will impact deployment flexibility, security, and long-term support.
Use environment variables when you need environment-specific configuration that rarely changes.
Use a configuration table when values may change at runtime or need to be maintained by non-developers.
Avoid hardcoding unless you're doing quick and disposable testing.
Making the right call here will help you avoid headaches down the line—and your future self (or the next developer after you) will thank you for it.
