In Business Central (BC), it is common to need to adapt the data model: change a field’s caption, rename tables, add extensions… However, not everything can be modified without risks.
Some changes are cosmetic and safe, while others can cause data loss, synchronization errors, or even prevent the SaaS environment from updating.
In this article we will cover:
- What happens if you change a field’s name (caption) in Business Central
- What happens if you change the ID
- Simple examples of both cases
- Technical explanation based on real behavior in BC
- Documented evidence in blogs and official documentation
What is the ID of a field in Business Central?
Each field in an AL table is defined as follows:
field(7; MyField; Text[50])
{
Caption = 'Customer';
}
The number 7 is the field’s actual ID in the database.
The name MyField is the AL identifier.
The caption is the text shown to the user.
Business Central does not use the field name to store data, but rather the ID.
This means that the data is tied to the ID, not to the name.
This is supported by real tests documented in Dynamics 365 Lab, where it is shown that changing the ID causes a complete loss of the field’s value during schema synchronization and requires ForceSync, which can damage data in SaaS.
Changing a field name in Business Central
✔ Safe
✔ Does not affect the data
Changing a field’s name or its caption only affects the interface, never the data, because the information remains linked to the ID.
Example:
Before:
field(7; MyField; Text[50])
{
Caption = 'Customer';
}
After:
field(7; MyField; Text[50])
{
Caption = 'Business Name';
}
Result:
- The field’s data remains intact
- No data storage is altered
- No data is lost
- Does not require ForceSync
Changing a field’s ID in Business Central
- Breaks the data
- Business Central treats it as a new field
- In SaaS it is practically forbidden
- Causes loss of information
Example:
Before:
field(7; MyField; Text[50]) { }
Afterwards (ID changed to 500):
field(500; MyField; Text[50]) { }
Consequences:
- Business Central interprets the field as a new one
- The data from the field with ID 7 becomes orphaned
- The new field 500 appears empty
- In SaaS, publishing fails unless you force ForceSync
- ForceSync can cause irreversible data loss in production
What happens when synchronizing a field in Business Central
Scenario 1: changing only the field name
Before:
- Field: ID 7
- Name: MyField
- Caption: "Customer"
- Stored value: "ACME S.A."
After:
- Field: ID 7
- Name: MyCompanyField
- Caption: "Company Name"
Result:
| ID | Previous value | Value after |
| 7 | ACME S.A. | ACME S.A. |
Everything is preserved.
Scenario 2: changing the field ID
Before:
- Field: ID 7
- Stored value: "ACME S.A."
After:
- Field: ID 500
Result:
| ID | Value |
| 7 | Orphaned / lost |
| 500 | (empty) |
BC interprets it as:
- "The field ID 7 no longer exists → delete it"
- "The field ID 500 is new → create it empty"
Safe alternatives when changing the ID in Business Central
In SaaS environments the answer is: DO NOT DO IT.
Safe alternatives:
- Create a new field and copy the data with an AL process
- Delete the old field only when it is already empty
- Never reuse IDs
- Never renumber IDs in production
These principles are reinforced in Microsoft's documentation related to schema handling and the Rename method, which makes it clear that structural changes must be handled with the utmost care.
Conclusions about modifying fields in Business Central
✔ Changing the field name does not affect the data.
❌ Changing the field ID does affect it, and it can cause data loss.
- Data in Business Central is tied to the ID, not to the name.
- Changing a name (caption) is safe.
- Changing an ID is equivalent to deleting a field and creating a new one.
- In SaaS it can cause synchronization errors and irreversible data loss.
- It should only be done in the early stages of development, never in production.
SaaS vs On‑Premise when changing a field ID or name
| Exchange rate | SaaS | OnPremise |
| Changing only the name (Caption or AL Name) | Safe. It does not affect data. Synchronization is Additive. BC keeps the original column and simply updates the metadata shown to the user. | Safe. It does not affect data. Exactly the same behavior. The caption is not linked to storage. |
| Changing the field ID | It does not remove the old field immediately, but the old column becomes orphaned and the new column is created empty. The data you see may come from the old column if the page is still pointing to it. There is a high risk: in future updates, the orphaned column may be removed. | It allows applying ForceSync, which actually deletes the old column and leaves only the new one (empty). Medium‑high risk: data loss if migration is not performed first. |
| Field data after the ID change | The extension sees a new empty field. The old field still exists in SQL but no longer belongs to the AL model. The data becomes inaccessible from your extension. | Data is lost when performing ForceSync. The old column is physically removed. |
| Real risk of data loss | Very high in the medium term. Even though it appears that nothing is lost, during a Microsoft upgrade the old column may be removed as part of schema cleanup. | Immediate when you apply ForceSync. If you do not migrate the data beforehand, it is lost. |
| Schema synchronization | Only Additive or Safe. SaaS does not allow ForceSync without Microsoft intervention. That is why the old column remains “hanging”. | You can run ForceSync freely, deleting old columns and altering the structure. |
| What the user sees on the page | Many times it displays the old data, because the page may still be internally linked to the old field. This creates a false sense of security. | The page usually displays the new empty field after ForceSync, because the old one is deleted. |
| Behavior in future updates | Microsoft may automatically remove old columns → permanent data loss. | There is no automatic cleanup: it is up to you to maintain or remove the schema. |
| General recommendation | NEVER change the ID in SaaS. Create a new field + migrate the data through code. | Avoid changing the ID unless it is strictly necessary. If you do, migrate the data first. |
| Conclusion by platform | Changing the name: safe. Changing the ID: breaks data even if it is not immediately visible. | Changing the name: safe. Changing the ID: requires migration + ForceSync and results in physical data loss. |
ABD, your partner expert in Business Central and secure development
In ABD Consulting and IT Solutions we have been helping companies evolve their management systems with Microsoft technology for more than 35 years. We specialize in Microsoft Dynamics 365 Business Central, both in SaaS and On‑Premise environments, and in the development of secure, maintainable AL extensions aligned with Microsoft best practices.
We know that seemingly small decisions —such as changing a field ID or modifying a data structure— can have a critical impact on stability, upgrades, and data integrity. That is why at ABD we not only develop, but also design architectures and customizations that protect your data and ensure future compatibility with Business Central.
If you need to adapt your ERP, migrate data, create extensions, or review existing developments to avoid risks in SaaS or during upgrades, our team can help you do it right from the start.
Contact ABD and ensure the evolution of your Business Central without putting your information at risk.