Configuration Keys

Configuration keys are AOT objects that control the availability of features, objects, and functionality within D365 F&O. Every AOT object — tables, fields, forms, menu items, EDTs, reports — can reference a configuration key. When that key is disabled, all associated objects become invisible and non-functional in the application.

Configuration keys provide a mechanism for:

• Bundling features — group related objects under a single key so an entire feature can be toggled on or off.
• License enforcement — tie functionality to licence codes so only licensed features are available.
• Environment customisation — disable unused modules or features to simplify the application for specific deployments.
• Conditional compilation — the compiler excludes code paths gated by disabled configuration keys, reducing the application footprint.

---

How Configuration Keys Work

When a configuration key is enabled, all objects referencing it are active — table fields exist in the database, form controls are visible, and menu items appear in navigation. When disabled:

• Table fields gated by the key are removed from the SQL table schema. A database synchronisation drops or adds the columns.
• Form controls are hidden from the UI.
• Menu items are removed from menus and navigation.
• Code paths behind isConfigurationkeyEnabled() checks are skipped.

danger

Disabling a configuration key that gates table fields triggers a database schema change. This can cause data loss if the fields contain data. Always back up data before disabling configuration keys in production.

---

Configuration Key Hierarchy

Configuration keys support a parent-child hierarchy. If a parent key is disabled, all child keys are automatically disabled regardless of their own Enabled setting.

For example:

• Trade (parent) — enables trade and logistics features.
  • TradeAgreement (child) — enables trade agreement functionality.
  • TradeStatistics (child) — enables statistical reporting.

Disabling Trade automatically disables both TradeAgreement and TradeStatistics.

---

Configuration Key Groups

Configuration Key Groups (AxConfigurationKeyGroup) organise related configuration keys for administrative convenience. Groups appear in the configuration key setup form and provide a logical grouping in the UI. Groups can also have parent groups, creating a hierarchical structure.

---

Standard Configuration Keys

Microsoft provides hundreds of configuration keys across modules. Examples include:

Configuration Key	Module	Description
LedgerBasic	General ledger	Core general ledger functionality
LogisticsBasic	Procurement	Core procurement and logistics
Asset	Fixed assets	Fixed asset management
Currency	General	Multi-currency support
CashDisc	AP / AR	Cash discount functionality
BankAccountTransType	Bank	Bank transaction types
PurchReq	Procurement	Purchase requisitions
SalesQuotation	Sales	Sales quotations

---

Creating a Configuration Key

In Visual Studio

1. Right-click your project → Add → New Item → Configuration → Configuration Key.
2. Set properties: Name, Label, Description.
3. Optionally set ParentKey to nest under an existing key.
4. Set EnabledByDefault to Yes if the feature should be active without explicit configuration.

Assigning to Objects

Reference the configuration key on any AOT object that should be gated:

Typical Use Case

When building a feature that is delivered as part of a larger module but should be independently toggleable:

---

Enabling and Disabling Keys

Configuration keys are managed in the D365 client at:

Organisation administration → Setup → Licensing → License configuration

Administrators check or uncheck keys in the hierarchical tree. After changing keys, a database synchronisation is required to apply schema changes for gated table fields.

warning

After changing configuration keys, the system enters maintenance mode and requires a database sync. Plan key changes during maintenance windows.