Cómo Extender los Business Events en Microsoft Dynamics 365 Finance & Operations

Cuando el estándar no es suficiente: añade la información que tu integración realmente necesita

Cómo Extender los Business Events en

Microsoft Dynamics 365 Finance & Operations

¿Qué son los Business Events y por qué existen?

Si trabajas con Dynamics 365 Finance & Operations, probablemente ya hayas escuchado el término Business Events. Pero, ¿qué son exactamente y para qué sirven?

En pocas palabras, los Business Events son notificaciones que D365 F&O envía automáticamente hacia el exterior cuando ocurre algo relevante dentro del sistema. Piénsalos como alertas que el sistema lanza cuando sucede un evento de negocio: una orden de compra aprobada, una factura publicada, un pago registrado, etc.

En la práctica, un Business Event funciona así: ocurre algo en D365 (una OC aprobada, una factura registrada, un pago realizado) 
y el sistema automáticamente envía un mensaje con los datos de ese evento hacia el sistema externo que lo esté escuchando, 
sin que nadie tenga que hacer nada manualmente.

Estas notificaciones se pueden enviar a diferentes destinos: Microsoft Power Automate, Azure Service Bus, Azure Event Grid, o cualquier endpoint HTTPS que tú configures. Esto los convierte en la base ideal para integraciones en tiempo real, automatizaciones y arquitecturas orientadas a eventos.

El problema: los Business Events estándar no siempre tienen lo que necesitas

Aquí viene la parte que todo consultor experimenta en algún momento de un proyecto: abres el catálogo de Business Events en D365, encuentras el evento que necesitas (digamos, “Purchase Order Confirmed”), lo configuras, y cuando empieza a dispararse… te das cuenta de que el payload (el paquete de datos que envía) no incluye todos los campos que tu integración necesita.

Por ejemplo, el evento de confirmación de orden de compra podría enviarte el número de orden, la fecha y el proveedor, pero no incluir el Centro de Coste, o el campo personalizado que añadiste para identificar el proyecto asociado. ¿Qué haces entonces?

Campo esperado¿Incluido por defecto?
Número de Orden de Compra✅ Sí
Proveedor✅ Sí
Fecha de confirmación✅ Sí
Centro de Coste❌ No siempre
Campo personalizado (extensión)❌ No
Dimensiones financieras completas❌ Parcialmente

Antes de que existiera la posibilidad de extender Business Events, las alternativas eran poco atractivas: crear un Business Event completamente nuevo desde cero (lo cual requería desarrollo complejo), hacer polling a la base de datos desde el sistema externo, o construir una integración basada en batch jobs con todos los problemas de latencia que eso implica.

La solución: extender el contrato de un Business Event existente

Microsoft introdujo la capacidad de extender los Business Events existentes mediante el patrón de extensión de X++ (el lenguaje de programación de D365). Esto significa que un desarrollador puede tomar un Business Event estándar y añadirle campos adicionales sin modificar el código base del producto.

Esta es una diferencia fundamental en la filosofía de desarrollo de D365: en lugar de modificar el código de Microsoft (lo que se llama “overlayering”, hoy en día desaconsejado), se crean extensiones que se agregan encima del código estándar. Así, cuando Microsoft actualiza el sistema, tus personalizaciones no se rompen.

🎯 Punto clave para el consultor funcional: extender un Business Event no requiere crear uno nuevo desde cero. 
Se toma el evento existente, se le añaden los campos que faltan, y el resultado es un evento enriquecido que fluye por 
los mismos canales de integración ya configurados.

¿Qué se necesita técnicamente?

Sin entrar en código profundo, el proceso implica tres pasos desde el lado técnico:

• Extender el contrato del evento: El “contrato” es la clase que define la estructura del mensaje (payload). Se crea una extensión de esa clase —usando el patrón [ExtensionOf] de X++— para añadir los nuevos campos.
• Poblar los nuevos campos via Chain of Command: Se extiende el método initialize() del contrato original para que, cuando el evento se dispare, los nuevos campos se llenen con los datos correctos. No se requiere ningún paso de registro manual separado.
• Reconstruir el catálogo de Business Events: Tras desplegar la extensión, hay que ir a Administración del sistema > Business Events > Administrar > Reconstruir catálogo para que D365 refleje los nuevos campos en el catálogo.

Casos de uso prácticos: ¿cuándo tiene sentido hacerlo?

Ahora la parte que más interesa a un consultor funcional: ¿en qué situaciones reales conviene extender un Business Event?

1. Campos personalizados en entidades estándar

Es muy común que en proyectos de implementación se añadan campos personalizados a entidades como órdenes de compra, órdenes de venta, o facturas de proveedor. Estos campos no existen en el estándar, por lo que nunca aparecerán en el payload original del Business Event.

Si tienes un campo “Referencia del contrato marco” en la orden de compra y tu sistema de gestión de contratos necesita recibirlo cuando la orden se confirma, la extensión del Business Event es la solución ideal.

2. Dimensiones financieras completas

Las dimensiones financieras son notoriamente difíciles de incluir en integraciones. Muchos Business Events estándar no las incluyen o las incluyen de forma parcial. Cuando el sistema destino necesita saber el Centro de Coste, la Unidad de Negocio, o el Departamento al que se imputa una transacción, extender el contrato permite añadir exactamente esas dimensiones.

3. Datos de líneas de documento

Algunos Business Events envían solo la cabecera del documento (por ejemplo, los datos generales de una factura) pero no las líneas (los artículos o servicios facturados). Aunque en este caso a veces conviene crear un Business Event nuevo, en otras situaciones es más eficiente extender el evento de cabecera para incluir un resumen de las líneas.

4. Datos de entidades relacionadas

A veces el evento dispara en la orden de compra, pero el sistema externo necesita datos del proveedor que no están en la orden misma: el segmento de proveedor, la categoría de riesgo, o un campo personalizado del registro de proveedor. La extensión permite navegar las relaciones de la base de datos y traer esos datos adicionales.

Escenario Solución recomendada
Por qué Añadir campos personalizados al payloadExtender Business Event existente Reutiliza la infraestructura ya configurada
Añadir dimensiones financierasExtender Business Event existenteEvita duplicar la lógica de disparo
Evento completamente nuevo (sin equivalente estándar)Crear nuevo Business EventNo existe base de la cual partir
Enviar datos de líneas cuando solo hay cabeceraEvaluar caso por casoPuede extenderse o crearse nuevo

Ventajas de este enfoque frente a las alternativas

vs. Crear un Business Event desde cero

Crear un Business Event nuevo requiere definir el punto de disparo (trigger), el contrato, el registro en el framework, y las pruebas completas. Extender uno existente aprovecha todo ese trabajo ya hecho por Microsoft y solo añade lo que falta. Menos código = menos riesgo en actualizaciones futuras.

vs. Batch jobs de sincronización

Los batch jobs que leen y sincronizan datos periódicamente tienen latencia (la integración no es en tiempo real), consumen recursos del sistema constantemente aunque no haya cambios, y son más difíciles de monitorear. Los Business Events son reactivos: solo se disparan cuando algo cambia.

vs. Servicios de datos OData o entidades de datos

OData es excelente para consultas bajo demanda (pull), pero no para notificaciones automáticas (push). Si el sistema externo necesita ser notificado inmediatamente cuando ocurre algo en D365, los Business Events son la herramienta correcta. Combinar ambos enfoques es también una estrategia válida.

⚠️ Consideración importante: la extensión de Business Events es una personalización de código X++, 
lo que significa que requiere un desarrollador con conocimientos de X++. Sin embargo, como consultor funcional, 
tu rol es clave: defines QUÉ datos necesita el sistema externo y en QUÉ momento deben enviarse. Esa especificación funcional 
es el insumo principal para el desarrollador.

El rol del consultor funcional en este proceso

Aunque la implementación técnica es responsabilidad del equipo de desarrollo, el consultor funcional tiene un papel fundamental en definir correctamente el alcance y los requisitos. Aquí tienes un checklist de las preguntas que deberías poder responder antes de solicitar la extensión:

• ¿Qué Business Event estándar se utilizará como base? (identifícalo en el catálogo de D365)
• ¿Qué campos adicionales necesita el sistema destino que no están en el payload actual?
• ¿De qué tabla o entidad de D365 provienen esos campos?
• ¿Existe alguna transformación o cálculo necesario, o son datos directos del sistema?
• ¿El sistema destino puede consumir el mismo endpoint/canal que ya está configurado, o necesita uno nuevo?
• ¿En qué entorno debe implementarse y cuáles son los criterios de aceptación?

Con estas respuestas bien documentadas, el desarrollo de la extensión se vuelve predecible y acotado, lo que reduce significativamente el riesgo del proyecto.

¿Cómo se ve esto en D365? (Perspectiva funcional)

Desde el lado funcional, una vez que la extensión está desarrollada y desplegada, la experiencia de configuración es idéntica a la de cualquier Business Event estándar. Vas a:

• Administración del sistema > Configuración > Business Events > Catálogo de Business Events

El evento extendido aparecerá con el mismo nombre que el original, pero al activarlo y revisar los datos que envía (por ejemplo, con una herramienta como Postman o directamente en Power Automate), verás los nuevos campos que se añadieron.

No hay ninguna configuración adicional especial desde la interfaz de usuario. La extensión es transparente para el usuario funcional que administra las integraciones.

Ejemplo práctico: Flujo de aprobación de Orden de Compra

El flujo de aprobación de órdenes de compra en D365 es uno de los escenarios más habituales donde los Business Events demuestran su valor. Vamos a usar como base el evento real que D365 dispara en este proceso y veremos dónde la extensión marca la diferencia.

El evento que se dispara: Workflow WorkItem

Cuando un comprador envía una OC al flujo de aprobación en D365, el sistema no dispara un evento específico de “OC enviada a aprobación”. Lo que dispara es el evento genérico de workflow Workflow WorkItem, cuyo identificador real en el sistema es PurchTableApproval_WorkItem. Este evento se genera en el momento en que D365 asigna la tarea de aprobación al usuario correspondiente, es decir, cuando el aprobador recibe el work item en su bandeja de workflow.

Este es precisamente el momento ideal para notificar al aprobador por un canal externo, como una tarjeta de aprobación en Microsoft Teams. El evento ya incluye quién debe aprobar, cuándo vence y un enlace directo a la OC en D365. El problema es que no incluye nada sobre la OC en sí.

El problema concreto: ¿qué le falta al Workflow WorkItem?

Quieres que Power Automate escuche este evento y construya automáticamente una tarjeta de aprobación en Teams. Para que esa tarjeta sea útil, el aprobador necesita ver:

• El número de OC y el proveedor — el esquema solo trae WorkflowOwner/WorkflowOriginator (emails), no datos de la OC en sí (❌)
• El importe total y la moneda — no están en el esquema estándar del WorkItem (❌)
• El nombre legible del solicitante — el esquema solo trae WorkflowOriginator como email, sin nombre ni cargo (❌)
• Las dimensiones financieras: Centro de Coste, Unidad de Negocio, Departamento — completamente ausentes del esquema (❌)
• Un resumen de las líneas de la OC — número de artículos, descripción principal, categoría de compra (❌)
• La fecha de entrega solicitada y el nombre legible del proveedor (no solo el código de cuenta) (❌)

⚠️ Sin la extensión, el sistema externo tendría que hacer una llamada adicional al API de D365 para buscar el aprobador, sus datos y las dimensiones financieras, cada vez que llegue una notificación. Esto añade latencia, complejidad y puntos de fallo a la integración.

La solución: extender el contrato del Workflow WorkItem

Con la extensión del contrato del Workflow WorkItem, el payload que recibe Power Automate ya contiene todo lo que necesita para construir la tarjeta de aprobación en Teams sin ninguna llamada adicional. Compara ambas versiones:

Payload estándar — Workflow WorkItem (PurchTableApproval_WorkItem):

{
  // Campos de contexto del evento
  "BusinessEventId": "PurchTableApproval_WorkItem",
  "BusinessEventLegalEntity": "USMF",
  "EventTimeIso8601": "2025-06-12T14:35:00Z",
  // Campos del workflow
  "WorkflowOriginator": "[email protected]",
  "WorkflowOwner": "[email protected]",
  "WorkflowUserEmail": "[email protected]",
  "InitiatingUserAADObjectId": "{a1b2c3d4-0000-0000-0000-000000000000}",
  "WorkflowComment": "",
  "WorkflowStepInstruction": "Aprobar orden de compra",
  "WorkflowDueDate": "2025-06-14T00:00:00Z",
  "LinkToWeb": "https://d365.empresa.com/?cmp=USMF&mi=PurchTable&...",
  "WorkflowTemplateName": "PurchTableTemplate_000063",
  "WorkflowCorrelationId": "{f1e2d3c4-...}",
  "WorkflowInstanceId": "{c7d8e9f0-...}",
  "WorkflowWorkItemSubject": "",
  "SerializedWorkflowDocumentData": null,
  // ❌ NO hay datos de la OC: número, proveedor, importe, moneda
  // ❌ NO hay nombre legible del solicitante ni del aprobador
  // ❌ NO hay dimensiones financieras
}

Es cierto que en algunos casos D365 incluye datos adicionales dentro del campo SerializedWorkflowDocumentData, un bloque de datos serializado que puede contener información del documento. Sin embargo, descomponer y aislar esa información en campos independientes dentro de Power Automate no es sencillo: obliga a usar expresiones complejas para parsear el contenido, duplicar esa lógica en cada acción del flujo que necesite el dato, y asumir una dependencia frágil sobre la estructura interna de ese campo, que puede cambiar entre versiones. El flujo se vuelve difícil de mantener y de entender para cualquier persona que lo retome. Un campo limpio y explícito en el payload es siempre la opción más robusta.

Payload extendido — Workflow WorkItem + extensión del contrato:

{
  // ── Campos estándar del esquema ───────────────────────────────
  "BusinessEventId": "PurchTableApproval_WorkItem",
  "BusinessEventLegalEntity": "USMF",
  "EventTimeIso8601": "2025-06-12T14:35:00Z",
  "WorkflowOriginator": "[email protected]",
  "WorkflowOwner": "[email protected]",
  "WorkflowUserEmail": "[email protected]",
  "WorkflowComment": "Urgente - cierre de trimestre",
  "WorkflowStepInstruction": "Aprobar orden de compra",
  "WorkflowDueDate": "2025-06-14T00:00:00Z",
  "LinkToWeb": "https://d365.empresa.com/?cmp=USMF&mi=PurchTable&...",
  "WorkflowTemplateName": "PurchTableTemplate_000063",
  // ── Campos añadidos por extensión del contrato ─────────────────
  // Datos de la Orden de Compra
  "PurchId": "PO-2025-00891",
  "VendorAccount": "V00034",
  "VendorName": "Suministros Tecnológicos S.A.",
  "TotalAmount": 48500.00,
  "CurrencyCode": "EUR",
  "DeliveryDate": "2025-07-01",
  // Dimensiones financieras
  "CostCenter": "CC-OPERACIONES",
  "BusinessUnit": "BU-NORTE",
  "Department": "IT",
  // Nombre legible del solicitante (para la tarjeta de Teams)
  "OriginatorName": "Ana García",
  "OriginatorTitle": "Responsable de Compras",
  // Resumen de líneas de OC
  "NumberOfLines": 3,
  "TopItemDescription": "Laptops Dell XPS 15 (x10)",
  "ProcurementCategory": "SUMINISTROS-IT"
}

¿Qué se gana con esto en la práctica?

Con el payload extendido, Power Automate puede construir directamente la tarjeta de aprobación en Microsoft Teams sin hacer ninguna llamada adicional a D365. El aprobador ve en su tarjeta de Teams: el número de OC, el nombre del proveedor, el importe, la fecha de entrega, quién lo solicita (con nombre, no solo email), las dimensiones financieras y el resumen de artículos. Todo en un solo mensaje. Además:

• El aprobador tiene contexto completo antes de decidir: sabe quién pide, cuánto es, a qué proveedor y con cargo a qué centro de coste — sin tener que entrar a D365.
• El WorkflowComment del esquema estándar ya trae el comentario del solicitante; combinado con los datos de la OC extendidos, la tarjeta de Teams es completamente autoexplicativa.
• Las dimensiones financieras añadidas permiten que el sistema de control presupuestario o ERP secundario registre el compromiso de gasto directamente al recibir el evento, sin consultas adicionales.
• El payload es autosuficiente: si Power Automate falla o Teams tiene un incidente, el mensaje se puede reprocesar con toda la información intacta, sin necesidad de llamadas API adicionales a D365 en el momento de la recuperación.

✅ Regla de oro en integraciones orientadas a eventos: un mensaje de notificación debe ser autosuficiente. 
El sistema receptor nunca debería necesitar “llamar de vuelta” al origen para completar la información. 
La extensión de Business Events es la herramienta que te permite lograrlo en D365 F&O.

Conclusión

Extender los Business Events de Dynamics 365 Finance & Operations es una de las herramientas más elegantes que tiene el ecosistema para resolver el gap entre lo que el estándar ofrece y lo que tus integraciones realmente necesitan.

Es una solución que respeta el principio de “no tocar el estándar” (fundamental para mantener el sistema actualizable), aprovecha la infraestructura de integración ya existente, y entrega datos enriquecidos en tiempo real a los sistemas que los necesitan.

Como consultor funcional, tu valor en este proceso está en identificar con precisión cuáles son esos datos adicionales, documentarlos correctamente, y asegurarte de que la integración resultante cubra el caso de negocio de extremo a extremo.

📌 Para recordar: extensión de Business Event = mismo evento, mismo canal, más datos. Simple conceptualmente, poderoso en la práctica.

Referencias

Para profundizar técnicamente en el tema, estas son las fuentes de referencia que recomendamos:

• Microsoft Learn — Business events overview

Punto de entrada conceptual: catálogo de eventos, activación, endpoints (Service Bus, Event Grid, Power Automate) y comportamiento idempotente. Lectura previa obligatoria antes de entrar en código.

learn.microsoft.com/…/business-events/home-page

• Microsoft Learn — Business events developer documentation

La referencia técnica oficial. Cubre el patrón completo de extensión de contratos existentes, los atributos [DataContract], [DataMember] y [BusinessEventsDataMember], el método buildContract() y mejores prácticas. Incluye el ejemplo completo con SalesInvoicePostedBusinessEventContract.

learn.microsoft.com/…/business-events/business-events-dev-doc

• Peter Ramer (Microsoft MVP) — How to Setup a Custom D365 Business Event

Microsoft MVP. Implementación completa paso a paso: clase contrato, clase base y método Chain of Command, con un caso real sobre albarán de pedido de venta. Buena plantilla de referencia para trabajar en Visual Studio.

dynamics365musings.com/how-to-setup-a-custom-d365-business-event

¿Tienes dudas o quieres compartir tu experiencia con Business Events? Déjanos un comentario abajo o únete a la conversación en nuestra comunidad de DynamicsRepublic.com