Add a field to a standard D365 F&O table and show it on a form

In Dynamics 365 Finance & Operations, you do not add a field by changing the Microsoft table: you create a table extension in your own model (for example InventTable.MyModel), add the field there, ideally put it in a field group, then build and synchronise the database. To show it, you create a form extension and add a control bound to the field or field group.

If the standard form already shows a field group, adding your field to that group is often enough to make it appear, without touching the form. That is why Microsoft recommends always building forms and reports from field groups.

1. In Application Explorer, right-click the table (e.g. InventTable) > Create extension, in your model.
2. In the designer, right-click Fields > New > the type you need, or drag an extended data type (EDT) or an enum from your project onto the Fields node. Prefer an EDT: it carries label, size and help text.
3. Set the properties (label, help). Create labels in a label file rather than hard-coded text.
4. Add the field to an existing field group or to a new group.
5. Build, then synchronise the database: the field is then visible and editable in the UI if it belongs to a group already shown.

A table extension also lets you add field groups, indexes, relations, mappings and methods (through an extension class), change an existing field's label, or replace its EDT with a derived EDT.

If the field does not appear through an existing group, create a form extension (right-click > Create extension). A form extension lets you add a control, enable or hide a control, change its label, add a data source or a form part. Add a control in the right tab or group and bind it to the data source and field (or field group).

To react to input or initialise the value, use Chain of Command or the table and data source events (ValidatedWrite, Inserting, ModifiedField…). See Chain of Command vs event handlers.

• Forgetting to synchronise the database: the field does not exist in SQL.
• Adding the field with no field group: you must then extend every form and report one by one.
• Creating a "bare" string field with no EDT: label, size and help must be redefined everywhere.
• Trying to change a standard unique index: extensions do not allow it.
• Using doInsert / doUpdate in your code: they do not raise data events and make the table harder to extend.
• Forgetting to expose the field in the data entity if integrations need it. See create and export a data entity with DMF.

Adding a field, its EDT, label, form and data entity: a typical ticket. Skalp AI writes the specification, generates the X++ code and unit tests, compiles with a best-practice check, then delivers a pull request to your Azure DevOps: nothing is merged without your technical architect's approval. See custom D365 F&O extensions, the bigger picture in building X++ without a consultant in 2026, and the Basic, Pro and Max plans (1 credit, ≈ €400 on Basic, €200 on Pro, consumed only when the code is generated).

See also: computed columns in a data entity.

• Microsoft Learn, "Add fields to tables through extension", updated 6 Mar 2026, accessed 18 Oct 2026.
• Microsoft Learn, "Customize through extension and overlayering", updated 27 Mar 2026, accessed 18 Oct 2026.
• Microsoft Learn, "Write extensible tables", updated 27 Mar 2026, accessed 18 Oct 2026.