En Business Central (BC) es habitual necesitar adaptar el modelo de datos: cambiar el caption de un campo, renombrar tablas, añadir extensiones… Sin embargo, no todo se puede modificar sin riesgos.
Algunos cambios son cosméticos y seguros, mientras que otros pueden provocar pérdida de datos, errores de sincronización o incluso impedir que el entorno SaaS se actualice.
En este artículo veremos:
- Qué pasa si cambias el nombre (caption) de un campo
- Qué ocurre si cambias el ID
- Ejemplos simples de ambos casos
- Explicación técnica basada en comportamiento real en BC
- Evidencia documentada en blogs y documentación oficial
¿Qué es el ID de un campo en Business Central?
Cada campo en una tabla AL se define así:
field(7; MyField; Text[50])
{
Caption = ‘Cliente’;
}
El número 7 es el ID real del campo en la base de datos.
El nombre MyField es el identificador de AL.
El caption es el texto mostrado al usuario.
Business Central no usa el nombre del campo para almacenar datos, sino el ID.
Esto significa que los datos viven asociados al ID, no al nombre.
Esto está corroborado por pruebas reales recogidas en Dynamics 365 Lab, donde se demuestra que un cambio de ID provoca pérdida total del valor del campo durante la sincronización del esquema y requiere ForceSync, lo que puede dañar datos en SaaS.
Cambiar el nombre de un campo en Business Central
✔ Seguro
✔ No afecta a los datos
Cambiar el nombre de un campo o su caption solo afecta a la interfaz, nunca a los datos, porque la información sigue vinculada al ID.
Ejemplo:
Antes:
field(7; MyField; Text[50])
{
Caption = ‘Cliente’;
}
Después:
field(7; MyField; Text[50])
{
Caption = ‘Razón Social’;
}
Resultado:
- Los datos del campo siguen íntegros
- No se altera el almacenamiento
- No hay pérdida de datos
- No requiere ForceSync
Cambiar el ID de un campo en Business Central
- Rompe los datos
- Business Central lo trata como un campo nuevo
- En SaaS está prácticamente prohibido
- Provoca pérdida de información
Ejemplo:
Antes:
field(7; MyField; Text[50]) { }
Después (ID cambiado a 500):
field(500; MyField; Text[50]) { }
Consecuencias:
- Business Central interpreta el campo como uno nuevo
- Los datos del campo con ID 7 quedan huérfanos
- El nuevo campo 500 aparece vacío
- En SaaS, la publicación falla a menos que fuerces ForceSync
- El ForceSync puede causar pérdida irreversible de datos en producción
Qué ocurre al sincronizar un campo en Business Central
Escenario 1: cambiar solo el nombre del campo
Antes:
- Campo: ID 7
- Nombre: MyField
- Caption: “Cliente”
- Valor almacenado: “ACME S.A.”
Después:
- Campo: ID 7
- Nombre: MyCompanyField
- Caption: “Razón Social”
Resultado:
| ID | Valor anterior | Valor después |
| 7 | ACME S.A. | ACME S.A. |
Todo se mantiene.
Escenario 2: cambiar el ID del campo
Antes:
- Campo: ID 7
- Valor almacenado: “ACME S.A.”
Después:
- Campo: ID 500
Resultado:
| ID | Valor |
| 7 | Huérfano / perdido |
| 500 | (vacío) |
BC lo interpreta como:
- “El campo ID 7 ya no existe → eliminarlo”
- “El campo ID 500 es nuevo → crearlo vacío”
Alternativas seguras al cambiar el ID en Business Central
En entornos SaaS la respuesta es: NO LO HAGAS.
Alternativas seguras:
- Crear un campo nuevo y copiar los datos con un proceso AL
- Eliminar el campo antiguo solo cuando ya esté vacío
- Nunca reutilizar IDs
- Nunca renumerar IDs en producción
Estos principios están reforzados en la documentación de Microsoft relacionada con el manejo de esquemas y el método Rename, que deja claro que las alteraciones estructurales deben manejarse con máximo cuidado.
Conclusiones sobre modificar campos en Business Central
✔ Modificar el nombre del campo no afecta a los datos.
❌ Modificar el ID del campo sí afecta, y puede provocar pérdida de datos.
- Los datos en Business Central viven ligados al ID, no al nombre.
- Cambiar un nombre (caption) es seguro.
- Cambiar un ID equivale a borrar un campo y crear otro nuevo.
- En SaaS puede causar errores de sincronización y pérdida irreversible de datos.
- Solo debe hacerse en fases iniciales del desarrollo, nunca en producción.
SaaS vs OnPremise al cambiar ID o nombre de un campo
| Tipo de cambio | SaaS | OnPremise |
| Cambiar solo el nombre (Caption o AL Name) | Seguro. No afecta a datos. La sincronización es Additive. BC mantiene la columna original y simplemente actualiza la metadata mostrada al usuario. | Seguro. No afecta a datos. Exactamente el mismo comportamiento. El caption no está vinculado al almacenamiento. |
| Cambiar el ID del campo | No elimina el campo antiguo de inmediato, pero la columna vieja queda huérfana y la nueva columna se crea vacía. Los datos que ves pueden ser de la columna antigua si la página todavía apunta a ella. Riesgo alto: en actualizaciones futuras, la columna huérfana puede eliminarse. | Permite aplicar ForceSync, lo que borra realmente la columna antigua y deja solo la nueva (vacía). Riesgo medioalto: pérdida de datos si no se migra primero. |
| Datos del campo después del cambio de ID | La extensión ve un campo nuevo vacío. El campo viejo sigue existiendo en SQL pero ya no pertenece al modelo AL. Los datos quedan inaccesibles desde tu extensión. | Los datos se pierden al hacer ForceSync. La columna vieja desaparece físicamente. |
| Riesgo real de pérdida de datos | Muy alto a medio plazo. Aunque aparente que no se pierde nada, en un upgrade de Microsoft la columna antigua puede ser eliminada por limpieza de esquema. | Inmediato cuando aplicas ForceSync. Si no migras los datos antes, se pierden. |
| Sincronización del schema | Solo Additive o Safe. SaaS no permite ForceSync sin intervención de Microsoft. Por eso la columna vieja queda “colgando”. | Puedes ejecutar ForceSync libremente, borrando columnas antiguas y alterando la estructura. |
| Qué ve el usuario en la página | Muchas veces ve el dato antiguo, porque la página puede seguir enlazada al campo viejo internamente. Esto genera una falsa sensación de seguridad. | La página suele mostrar el nuevo campo vacío tras ForceSync, porque el viejo se borra. |
| Comportamiento en actualizaciones futuras | Microsoft puede eliminar automáticamente columnas antiguas → pérdida definitiva de datos. | No hay limpieza automática: depende de ti mantener o borrar esquema. |
| Recomendación general | NUNCA cambiar ID en SaaS. Crear campo nuevo + migración de datos vía código. | Evitar cambiar ID si no es estrictamente necesario. Si se hace, migrar antes los datos. |
| Conclusión por plataforma | Modificar nombre: seguro. Cambiar ID: rompe datos aunque no se vea inmediatamente. | Modificar nombre: seguro. Cambiar ID: requiere migración + ForceSync y causa pérdida física. |
ABD, tu partner experto en Business Central y desarrollo seguro
En ABD Consultoría y Soluciones Informáticas llevamos más de 35 años ayudando a empresas a evolucionar sus sistemas de gestión con tecnología Microsoft. Somos especialistas en Microsoft Dynamics 365 Business Central, tanto en entornos SaaS como On-Premise, y en el desarrollo de extensiones AL seguras, mantenibles y alineadas con las buenas prácticas de Microsoft.
Sabemos que decisiones aparentemente pequeñas —como cambiar el ID de un campo o modificar una estructura de datos— pueden tener un impacto crítico en la estabilidad, las actualizaciones y la integridad de la información. Por eso, en ABD no solo desarrollamos, sino que diseñamos arquitecturas y personalizaciones que protegen tus datos y garantizan la compatibilidad futura con Business Central.
Si necesitas adaptar tu ERP, migrar datos, crear extensiones o revisar desarrollos existentes para evitar riesgos en SaaS o en actualizaciones, nuestro equipo puede ayudarte a hacerlo bien desde el principio.
Contacta con ABD y asegura la evolución de tu Business Central sin poner en riesgo tu información.