Configuration Key vs. Parameter in Dynamics 365 Finance & Operations
Question 3 — Two ways to make customizations modular and switchable, and when to use each.
Interview Question
Model Answer (Short)
A Configuration Key controls whether a feature is available system-wide — when it is disabled, the associated tables, fields, menu items and code are switched off for the entire environment (the tables don't even exist in the underlying database). A Parameter controls behaviour at a company (legal entity) level, allowing different settings per company, and is stored in a parameter table. In short: use a configuration key for on/off at the system level and a parameter when behaviour must vary between companies.
Detailed Explanation
Configuration Key
- Determines whether developed functionality is available to the entire system.
- When disabled, related tables, fields, indexes and menu items are removed from the database.
- Every new table, view and menu item should be assigned a configuration key.
- Best used when a feature should be activated/deactivated at a system-wide level.
Parameter
- Controls how functionality behaves and allows different settings per company.
- Stored in a parameter table — a new parameter table for a new module, or extend the existing one.
- Best used when a feature should be switched on/off at the company level.
- Should follow the same pattern as standard parameter tables.
Prerequisites (Rule 5)
- Visual Studio with the Dynamics 365 developer tools.
- A custom model / package for your objects.
- A configuration key object in the AOT (for the config-key approach).
- A parameter table with an appropriate EntireTable cache lookup (for the parameter approach).
Code Example — Checking a configuration key
Guard a block of code so it only runs when a configuration key is enabled:
// Simple check — but this call is expensive if done repeatedly
if (isConfigurationKeyEnabled(configurationKeyNum(AbcNewModule)))
{
// Execute feature code
}Performance-friendly pattern (cache the result)
Because isConfigurationKeyEnabled() is expensive, evaluate it once during initialisation and cache
it in a member variable:
public class AbcInvoiceHandler
{
boolean isConfigEnabled;
public void initialize()
{
// Check the config key once and store the result
if (isConfigurationKeyEnabled(configurationKeyNum(AbcNewModule)))
{
isConfigEnabled = true;
}
}
private void createInvoiceReport()
{
if (isConfigEnabled)
{
// Perform operation
}
}
}Reading a parameter value
AbcParameters parameters = AbcParameters::find();
if (parameters.EnableAutoApproval)
{
// Behaviour that varies per company
}Configuration Key vs. Parameter
| Aspect | Configuration Key | Parameter |
|---|---|---|
| Scope | Entire system / environment | Per company (legal entity) |
| Effect when disabled | Tables & fields removed from the database | Data still exists; behaviour just changes |
| Storage | Configuration key object in the AOT | Parameter table record |
| Typical use | Turn a whole feature/module on or off | Tune behaviour differently per company |
| Checked in X++ with | isConfigurationKeyEnabled() |
ParametersTable::find() |
Points the interviewer wants to hear
- Configuration key = system-wide; parameter = per company.
- Disabling a config key physically removes its tables/fields from the database.
- Every new table, view and menu item should carry a configuration key.
isConfigurationKeyEnabled()is expensive — cache it ininit.- Feature Management is Microsoft-only and not a substitute for config keys on partner projects.
Likely Follow-up Questions
- What happens to existing data when you disable a configuration key?
- Why should you cache the result of
isConfigurationKeyEnabled()? - Can you use Feature Management instead of configuration keys? Why or why not?
Key Takeaway
Choose a configuration key to switch an entire feature on or off across the system, and a parameter when the same feature must behave differently in each company. Always cache config-key checks for performance.