Si estás leyendo esto, probablemente ya has trabajado con Power Apps, has configurado Business Rules, quizás has creado algunos flujos en Power Automate, y ahora te has topado con un problema que ninguna de esas herramientas puede resolver. Bienvenido al mundo de los plugins.
Objetivos de aprendizaje
- Comprender qué es realmente un plugin y cuándo tiene sentido usarlo
- Identificar los escenarios donde plugins son la única opción viable
- Conocer las limitaciones y restricciones que debes considerar
- Tomar decisiones informadas sobre cuándo usar plugins vs otras alternativas
El momento en que las herramientas low-code no son suficientes
Imagina esta situación: María es desarrolladora en una empresa de seguros. El equipo de negocio le pide implementar un sistema de numeración automática para las pólizas. El formato debe ser: AÑO-REGIÓN-SECUENCIAL, por ejemplo "2026-NORTE-00142".
María intenta varias aproximaciones. Primero prueba con un campo calculado, pero rápidamente descubre que los campos calculados no pueden acceder a otros registros ni mantener contadores. Luego intenta con Power Automate, pero el flujo se ejecuta de forma asíncrona: cuando el usuario guarda la póliza, el número aparece vacío por unos segundos, lo que confunde a los agentes de seguros.
Además, necesita que el número se genere de forma atómica para evitar duplicados cuando dos agentes crean pólizas simultáneamente. Power Automate no ofrece ese nivel de control sobre transacciones.
María necesita código que se ejecute de forma síncrona, antes de que el registro se guarde, con acceso completo a la base de datos y control transaccional. Necesita un plugin.
Entonces, ¿qué es exactamente un plugin?
Un plugin es una clase escrita en C# (o VB.NET, aunque nadie lo usa en la práctica) que se ejecuta en respuesta a eventos del sistema en Dataverse. Cuando alguien crea un registro, lo actualiza, lo elimina, o realiza prácticamente cualquier operación, Dataverse dispara eventos. Un plugin es código que intercepta esos eventos y puede hacer cosas antes, durante o después de la operación.
Técnicamente hablando, un plugin es un ensamblado .NET (un archivo DLL) que implementa la interfaz IPlugin del namespace Microsoft.Xrm.Sdk. Este ensamblado se sube a Dataverse y se registra para ejecutarse en eventos específicos.
Esta característica es fundamental. Un Business Rule se ejecuta en el formulario, así que si alguien importa datos desde Excel, el Business Rule no se dispara. Un plugin se ejecuta siempre, sin importar cómo llegue la operación.
Cuándo realmente necesitas un plugin
He trabajado con decenas de organizaciones implementando Dynamics 365, y he visto una y otra vez el mismo error: desarrolladores que saltan directamente a escribir plugins para todo. Los plugins son poderosos, pero tienen un coste: requieren desarrollo, testing, despliegue y mantenimiento. Antes de escribir un plugin, siempre me pregunto: ¿puedo resolver esto con las herramientas low-code?
Hay situaciones donde la respuesta es claramente "no". Estos son los casos donde los plugins brillan:
Validaciones complejas que requieren lógica de negocio
Carlos trabaja en una empresa de distribución. Antes de aprobar un pedido, el sistema debe verificar que el cliente tiene crédito suficiente, que los productos están en stock en el almacén más cercano, y que la dirección de envío está dentro de la zona de cobertura. Esta validación requiere consultar múltiples tablas y aplicar reglas de negocio complejas. Un Business Rule no puede hacer esto.
Cálculos que dependen de datos externos o relacionados
El equipo de finanzas necesita que al crear una factura, el sistema calcule automáticamente los impuestos basándose en la ubicación del cliente, el tipo de producto, y las reglas fiscales vigentes. Esto requiere consultar tablas de configuración, aplicar lógica condicional compleja, y actualizar múltiples campos. Los campos calculados no tienen este alcance.
Operaciones que deben ser síncronas y transaccionales
Cuando se cierra una oportunidad como ganada, el sistema debe crear automáticamente un proyecto, asignar recursos, y enviar notificaciones. Si cualquiera de estos pasos falla, todo debe revertirse. Power Automate es asíncrono y no participa en la transacción de Dataverse.
Integración en tiempo real con sistemas externos
Al crear un contacto, el sistema debe verificar en tiempo real con un servicio externo si el email existe y es válido. El usuario no debe poder guardar el registro hasta que esta validación se complete. Un flujo de Power Automate no puede bloquear la operación de guardado.
Auditoría y logging personalizado
Aunque Dataverse tiene auditoría nativa, algunas organizaciones necesitan registrar cambios en formatos específicos, enviar eventos a sistemas externos de monitoreo, o mantener históricos personalizados. Los plugins pueden interceptar cualquier cambio y procesarlo como sea necesario.
La jerarquía de decisión: plugins como último recurso
Un principio que sigo siempre: usa la herramienta más simple que resuelva el problema. Los plugins están al final de la jerarquía por una razón.
Antes de escribir código, considera esta secuencia:
Configuración nativa primero. ¿Puedes resolver el problema con campos calculados, rollup fields, o configuración de la entidad? Estas opciones no requieren código y son las más fáciles de mantener.
Business Rules para validaciones de formulario. Si la lógica se puede expresar como condiciones simples sobre campos del mismo registro, un Business Rule es más fácil de crear y mantener que código.
Power Automate para automatizaciones asíncronas. Si no necesitas que la operación sea síncrona ni participar en la transacción, un flujo es más flexible y visual que un plugin.
JavaScript para lógica de interfaz. Si la lógica solo aplica cuando el usuario trabaja desde un formulario específico, JavaScript en el formulario puede ser más apropiado.
Plugins cuando nada más funciona. Solo cuando las opciones anteriores no cubren el requisito, es momento de escribir un plugin.
Las restricciones que debes conocer desde el principio
Los plugins en Dataverse se ejecutan en un entorno sandboxed. Esto significa que hay límites estrictos sobre lo que pueden hacer, diseñados para proteger la estabilidad del sistema. Conocer estos límites antes de empezar a desarrollar te ahorrará dolores de cabeza.
El tiempo es tu enemigo
Un plugin síncrono tiene un máximo de 2 minutos para completar su ejecución. Suena como mucho tiempo, pero no lo es. Este límite es acumulativo: si tienes tres plugins registrados en el mismo evento y cada uno tarda 50 segundos, la operación fallará por timeout.
Pero el impacto real es la experiencia del usuario. Si tu plugin tarda 5 segundos, el usuario verá el formulario congelado durante 5 segundos cada vez que guarde. Multiplica eso por cientos de operaciones al día y tendrás usuarios frustrados.
La regla práctica: un plugin debería tardar milisegundos, no segundos. Si necesita más tiempo, probablemente debería ser asíncrono.
El sandbox limita tus opciones
No puedes hacer todo desde un plugin. Estas son algunas de las restricciones más importantes:
No puedes acceder al sistema de archivos del servidor. No puedes instalar dependencias arbitrarias. No puedes crear threads adicionales. Solo puedes tener 2 conexiones HTTP concurrentes. Las llamadas HTTP tienen un timeout de 60 segundos.
Esto tiene implicaciones prácticas. Si necesitas llamar a 10 servicios externos, tienes que hacerlo secuencialmente o de 2 en 2. Si un servicio externo está lento, tu plugin también lo estará.
La profundidad máxima
Cuando un plugin dispara otra operación que a su vez dispara otro plugin, esto crea una cadena. Dataverse limita esta cadena a 8 niveles de profundidad. Si tu diseño causa chains más largos, las operaciones fallarán.
Esto sucede más fácilmente de lo que parece. Un plugin en Create de Oportunidad que crea un Producto relacionado, cuyo plugin de Create actualiza el Inventario, cuya actualización dispara un recálculo de Pedidos... puedes llegar a 8 niveles sin darte cuenta.
El tamaño del assembly
El archivo DLL de tu plugin no puede superar los 16 MB. Esto rara vez es un problema, pero si incluyes dependencias grandes, puedes toparte con este límite.
El impacto real de un plugin mal diseñado
Hay algo que muchos desarrolladores no entienden hasta que lo ven en producción: un plugin afecta a TODOS los usuarios del sistema.
Si escribes un plugin que tarda 3 segundos en ejecutarse y lo registras en el evento Update de la entidad Account, cada vez que cualquier usuario modifique cualquier cuenta, esperará 3 segundos adicionales. Esto incluye importaciones masivas, integraciones, flujos de Power Automate, y cualquier proceso que toque esa tabla.
He visto organizaciones donde un solo plugin mal optimizado causaba que las importaciones nocturnas tardaran 12 horas en lugar de 1 hora. Y lo peor: nadie lo detectó durante meses porque cada operación individual "solo" tardaba un poco más.
Por eso la regla más importante del desarrollo de plugins es: mide el rendimiento desde el primer día. No asumas que tu plugin es rápido. Demuéstralo con datos.
Puntos clave
- Un plugin es código C# que se ejecuta en respuesta a eventos en Dataverse, interceptando operaciones antes, durante o después de que ocurran
- Los plugins se ejecutan en el servidor, así que se disparan independientemente de cómo llegue la operación (formulario, API, importación, flujos)
- Usa plugins solo cuando las herramientas low-code no pueden resolver el problema: validaciones complejas, cálculos con datos relacionados, operaciones transaccionales síncronas
- Los plugins tienen restricciones de sandbox: 2 minutos de timeout, 8 niveles de profundidad, 2 conexiones HTTP concurrentes
- Un plugin lento afecta a TODOS los usuarios y procesos del sistema, no solo a quien lo dispara