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

1. Environment Variables (Recommended for Most Scenarios)

  • 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.

Comments

Post a Comment

Popular posts from this blog

Effective Strategies for Debugging Plugins in Dynamics CRM

Image
In a recent interview, I was asked about debugging plugins in Dynamics CRM. The interviewer specifically wanted to know my approach to plugin debugging. In response, I mentioned using the Plugin Registration Tool profiler. However, I later realized there are multiple methods to debug plugins in Dynamics CRM/Dataverse, each essential for efficient troubleshooting. Debugging plays a crucial role in development, and having a solid understanding of various debugging approaches can help streamline issue resolution in Dynamics 365. Here, I'll explore different techniques for debugging plugin code. There are below options to use in the plugin in Dynamics CRM/Dataverse ITracingService : In Dynamics CRM plugin development, ITracingService is a service provided within the plugin's execution context that logs information for tracing and debugging. It allows developers to capture real-time. Plugin Profiler : A plugin profiler in Dynamics CRM (or Dataverse) is a debugging tool in the Plugi...
Read more

Connecting the Dots: FetchXML and Web API Integration in Dataverse

Image
 In Dataverse, FetchXML and the Web API are two powerful mechanisms for retrieving data and interacting with entities. Here's a brief overview of each and how they can be integrated: 1.    FetchXML :      -   Definition:   FetchXML is a proprietary query language used in Microsoft Dynamics 365 and Dataverse for querying data from entities.    -   Usage:   FetchXML queries can be used to retrieve data based on complex criteria, perform aggregations, and filter records.    -   Features:   FetchXML supports various query expressions, including conditions, sorting, grouping, and aggregation functions.    -   Integration:   FetchXML queries can be executed programmatically using client-side scripting, server-side code, or through tools like the Dynamics 365 Web API. 2.    Web API :      -   Definition:  ...
Read more

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse

Image
In Dynamics CRM/Dataverse, solutions are central to Application Lifecycle Management (ALM) , providing a structured way to manage, package, and distribute customizations across environments. Microsoft uses solutions to transfer apps and customizations by exporting them from one Dataverse environment and importing them into another.  Each solution is authored and maintained by a publisher and includes components like Power Apps (canvas and model-driven), flows, entities, forms, connectors, web resources, and configurations—excluding business data. Solutions streamline ALM practices within Microsoft Power Platform. In Dynamics CRM/Dataverse, there are two types of solutions: Managed and Unmanaged . When planning an implementation, it’s important to understand the advantages and disadvantages of each to make an informed decision. Let’s explore both types to determine the best approach for development and deployment. In Dynamics 365 CRM, a managed solution is a fully packaged solution ...
Read more

L1, L2, and L3 Support Explained

Image
  L1, L2, and L3 Support Explained In IT and software support, L1 (Level 1), L2 (Level 2), and L3 (Level 3) represent different tiers of technical support, each handling issues of varying complexity. 1️⃣ L1 Support (Level 1 - Frontline Support) Role: First point of contact for users/customers Responsibilities: Handles basic issues such as password resets, user access, and general troubleshooting. Uses a knowledge base or predefined scripts to resolve common problems. Escalates complex issues to L2 if not resolved. Communicates with customers via phone, chat, or email. Records tickets in a helpdesk system (e.g., ServiceNow, Jira, Zendesk). 🔹 Example: A user is unable to log in due to incorrect credentials → L1 resets the password. 2️⃣ L2 Support (Level 2 - Technical Support) Role: More in-depth troubleshooting and problem-solving Responsibilities: Resolves moderate to complex technical issues that L1 cannot handle. Analyzes logs, configurations, and system...
Read more

Model-Driven Apps Command Bar: A Guide to PrimaryControl and SelectedControl

Image
The command bar in Power Apps model-driven apps is a toolbar that lets users perform actions. You can customize it by adding buttons that run your own logic, either using Power Fx or JavaScript. This logic can work with a single data record or multiple records, depending on where the button is placed. The CrmParameter in the ribbon of Dynamics CRM (now Dynamics 365) is a special parameter used in the ribbon's button definitions or commands. It provides contextual information about the entity or record within the CRM system when the ribbon button is clicked. Purpose of CrmParameter CrmParameter is primarily used to pass specific CRM-related data to a custom JavaScript function, URL, or command action. It helps in retrieving dynamic data based on the current context, such as entity IDs, selected records, or even the page's user interface settings. 1. PrimaryControl Definition : Refers to the main form context or entity record currently being displayed or interacted with in the ap...
Read more

How to Write and Understand a Dynamics CRM Plugin

Image
 Here’s a sample plugin code in Dynamics CRM written in C#, along with a detailed explanation of each line. This plugin will update the "Description" field of an entity whenever a record is created. Sample Plugin Code using System; // For basic .NET types using Microsoft.Xrm.Sdk; // Provides key interfaces for CRM plugin development using Microsoft.Xrm.Sdk.Query; // For performing queries against CRM data namespace SamplePluginNamespace // Custom namespace for the plugin { public class SamplePlugin : IPlugin // Plugin class implementing the IPlugin interface { public void Execute(IServiceProvider serviceProvider) { // STEP 1: Retrieve the context of the plugin IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); if (context.MessageName != "Create" || context.St...
Read more

Stop Struggling with Plugins: Learn IOrganizationService the Smart Way

Image
Have you ever deployed a Dataverse plugin, only to watch it fail silently or act unpredictably? Most of the time, the missing piece is understanding how to communicate with Dataverse the smart way—using IOrganizationService . In the world of Dataverse, every plugin waits for its turn when something changes. The plugin looks around and wonders, “How do I talk to the database?” That’s when IOrganizationService steps in like a trusted messenger, ready to carry out requests and bring back results. “ Need to create a record? I can handle that,” it says. “ Want to update or delete data safely ? Leave it to me.” It even speaks the secret language of Dataverse messages like Assign and SetState . But it never works alone— IOrganizationServiceFactory brings it to life, deciding whether it should act as the user or as the powerful system account. Working together with IPluginExecutionContext , it always knows who triggered the action, which record is involved, and when to respond. What is IOrgan...
Read more

Decode and Fix: “This Data Type is Unsupported for Evaluation” in Power Apps

Image
 One common frustration when building Canvas Apps over Dataverse is encountering this cryptic error:  “This data type is unsupported for evaluation” This message typically appears when Power Apps cannot process or render a specific Dataverse column type within a control or formula. While it may seem vague, it’s usually tied to specific patterns involving complex column types or runtime data structure mismatches. In this blog, we'll explore common causes, scenarios, and practical fixes from both a developer and architectural standpoint. Root Causes of the Error 1. Polymorphic Lookups Dataverse supports polymorphic relationships (e.g., `Owner`, `Customer`, `Regarding`) that can point to multiple entity types. These lookups can't be directly evaluated in Power Apps unless you cast the reference explicitly. Use: If(     IsType(ThisItem.Customer, Account),     AsType(ThisItem.Customer, Account).Name,     AsType(ThisItem.Customer, Contact).FullName ) 2....
Read more

Architect’s Blueprint: How IPluginExecutionContext Powers the Plugin Pipeline

Image
 When a plugin executes in Dataverse, the IPluginExecutionContext acts like a navigator for the entire journey. It tells the plugin which message triggered the execution (such as Create, Update, or Delete), which entity and record are involved, and who initiated the action. It also provides critical runtime data, including pipeline stage, transaction behavior, depth for recursion control, and pre/post entity images . This contextual awareness allows the plugin to make smart decisions: whether to proceed, modify data, trigger additional operations, or abort the transaction. It also ensures that any changes are atomic—if one step fails, the entire transaction can roll back to maintain data integrity. For solution architects, this understanding translates into better design decisions, such as when to run logic synchronously or asynchronously, how to prevent recursive loops, and how to leverage pre/post images for auditing and automation. In essence, IPluginExecutionContext is the co...
Read more

Microsoft Dataverse : A Complete Storage

Image
Database generally refers to organized and structural databases that improve data storage and access performance, but E. F. Cod was given a new concept called relational database in 1970s. In the continuous journey of databases, object oriented, NoSQL, graphs and other new database concepts are added. Nowadays, Microsoft Dataverse defines a new definition of database that lets users design their own data model without writing single code. Microsoft Dataverse is cloud based managed service which provides  data service and app platform. Microsoft Dataverse is a combination of several Azure services, being exposed through the API layer which makes it easy to request data, but also allows it to be managed through the API layer. It is easy to manage and secure data with rich metadata, logic and validation layer with multiple productivity tools. All components  created in Dataverse are held as Metadata. This means the components are discoverable and the properties for components are...
Read more