Dynamics 365 rara vez llega solo. Llega con Dataverse debajo, con Power Platform al costado, con Entra ID gobernando las identidades y con un área de TI que tiene políticas escritas sobre qué conectores se pueden usar y cuáles no. Integrar firma electrónica en ese contexto es menos un problema de programación y más un problema de arquitectura y gobierno.
La buena noticia es que ese mismo entorno ofrece los componentes para hacerlo bien: almacenamiento de secretos, separación de ambientes, despliegue por soluciones y trazabilidad de auditoría. La mala es que si la integración se arma con un flujo rápido creado por un usuario en su cuenta personal, funciona un mes y se rompe el día que esa persona sale de la empresa.
Qué módulo dispara la firma
Antes de elegir tecnología conviene ubicar el punto exacto del proceso donde nace el documento firmable. Cambia mucho el diseño:
- Sales: cotizaciones aprobadas y contratos comerciales. El disparador suele ser un cambio de estado de la oportunidad; el firmante es un apoderado con facultades.
- Customer Service y Field Service: actas de conformidad, órdenes de trabajo cerradas en sitio. Aquí el volumen es alto y el firmante puede ser el técnico o el cliente.
- Finance and Operations: comprobantes, notas de crédito y documentos con efecto tributario. Es el escenario más exigente porque el formato lo define la administración tributaria, no la empresa.
- Human Resources: contratos, adendas y actas de finiquito, con volumen concentrado en fechas puntuales.
Cada uno tolera latencias distintas. Un acta firmada en sitio necesita respuesta en segundos; una tanda de contratos de nómina puede procesarse por lote durante la noche.
Plugin, flujo o middleware: la decisión de fondo
| Opción | Dónde corre | Ventaja | Límite |
|---|---|---|---|
| Plugin de Dataverse | Dentro de la plataforma, sobre eventos del modelo de datos | Se dispara siempre, sin depender de que alguien active un flujo | Ejecución acotada en tiempo: no sirve para operaciones largas |
| Flujo de Power Automate | Sobre la plataforma, con conectores | Rápido de construir y de modificar por el área funcional | Depende de conexiones y de políticas de datos; requiere gobierno |
| Servicio intermedio propio | Fuera de la plataforma | Control total de reintentos, colas y almacenamiento de claves | Requiere infraestructura y equipo que lo mantenga |
| Conector personalizado | Definición publicada en el entorno | Reutilizable por varios flujos y aplicaciones | Su versionado y su gobierno hay que administrarlos |
El patrón que mejor envejece en implantaciones grandes es mixto: el plugin detecta el evento y encola, el servicio intermedio hace la operación de firma y devuelve el resultado, y un flujo se encarga de las notificaciones a las personas. Así ninguna capa hace algo para lo que no fue diseñada. El detalle general de este tipo de arquitectura está en cómo integrar una API de firma electrónica.
El certificado no se guarda en el CRM
Es una regla sin excepciones: la clave privada no vive en un campo de Dataverse, ni en una variable de entorno de la solución, ni en un archivo adjunto de una nota. Cualquiera de esas ubicaciones es legible para quien tenga permisos de exportación o de administración del entorno, y una exportación de solución se lleva el secreto a un archivo que circula por correo.
Las ubicaciones aceptables son un almacén de secretos gestionado, un módulo de hardware o el propio entorno del proveedor cuando se usa firma en la nube. En los tres casos, Dynamics no maneja la clave: maneja una identidad autorizada a pedir una operación de firma, y esa autorización se puede revocar sin tocar el certificado.
La contracara es el control de acceso: quién puede invocar esa operación, con qué documentos y en qué horarios. Vale la pena registrarlo en el mismo registro de auditoría del CRM, para que la traza de un documento firmado se pueda reconstruir sin salir del sistema. El enfoque de control centralizado está desarrollado en firma electrónica centralizada para equipos.
Ambientes, soluciones y el error del endpoint compartido
Dynamics separa ambientes de desarrollo, pruebas y producción, y el despliegue viaja en soluciones. La integración de firma tiene que respetar esa separación con dos reglas concretas:
- La dirección del servicio de firma es una variable de entorno, no un valor fijo en el código. De lo contrario, la primera importación a producción arrastra el destino de pruebas o al revés.
- Pruebas nunca firma con el certificado de producción. Un ambiente de pruebas con datos clonados y certificado real produce documentos firmados que parecen válidos y que nadie sabe de dónde salieron.
Conviene además marcar los documentos generados en ambientes que no son producción, para que una copia extraviada no se confunda con un original.
Validez en el tiempo: sello de tiempo y revocación
Un contrato firmado hoy puede tener que sostenerse dentro de cinco años, cuando el certificado ya venció. Para eso existen dos piezas que suelen quedarse fuera del alcance del proyecto:
- Sello de tiempo: una marca temporal emitida por una autoridad de sellado que prueba que el documento existió y estaba firmado en ese instante. Sin ella, la verificación futura depende de la hora del equipo que firmó, que no prueba nada.
- Estado de revocación: la comprobación de que el certificado no había sido revocado al momento de firmar, mediante consulta en línea o listas de revocación. Incluir esa evidencia dentro del documento permite validarlo después sin conexión a los servicios del emisor.
Que el proveedor incluya o no estos elementos, y en qué nivel de perfil, es una pregunta concreta para la etapa de selección; está incluida en el checklist de proveedor de firma electrónica. Del lado de la verificación posterior, el método está en validación programática de firmas.
Dónde queda el documento firmado
Dataverse no es un repositorio documental. Guardar cientos de miles de PDF firmados dentro del almacenamiento del CRM encarece el ambiente y complica las copias. La práctica habitual es integrar la biblioteca documental corporativa y dejar en el registro del CRM la referencia, el hash del archivo y el estado de la firma. Ese modelo, con sus advertencias sobre versionado, está tratado en firma electrónica con SharePoint y OneDrive.
El hash almacenado en el CRM cumple una función adicional: permite detectar que el archivo del repositorio fue reemplazado, aunque el nombre siga siendo el mismo.
Fallos frecuentes en producción
- Conexiones a nombre de una persona: el flujo deja de funcionar cuando esa cuenta se deshabilita. Las integraciones se montan sobre identidades de aplicación.
- Políticas de prevención de pérdida de datos que bloquean el conector recién en producción, porque en desarrollo la política era distinta.
- Reintentos sin idempotencia, que generan dos documentos firmados del mismo contrato.
- Cadena de certificados incompleta en el documento resultante, que hace que un validador externo lo rechace aunque la firma sea buena. La causa y su solución están en qué significa el error de cadena de certificados.
Certificados para el proyecto
Firmas.com.ec emite certificados de firma electrónica con trámite 100% en línea y entrega en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI. Para una implantación de Dynamics, lo relevante es definir quiénes son firmantes reales frente a terceros y no comprar un certificado por usuario del CRM. El precio actualizado está en la página de precios.
Si el módulo financiero emite comprobantes electrónicos en Ecuador, el grupo también ofrece Azur, facturación electrónica autorizada por el SRI, que resuelve el ciclo completo del comprobante: azur.com.ec.
La coordinación que ninguna integración captura
El grupo también desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida.
En implantaciones de Dynamics suele haber un hueco entre el registro del CRM y la conversación real con el cliente, que ocurre por WhatsApp o por teléfono y no queda en ningún lado. Omnifox centraliza esos canales con historial por cuenta, asignación por responsable y métricas de respuesta. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede firmar desde un plugin de Dataverse directamente?
Se puede invocar el servicio desde el plugin, pero la operación completa no debería ejecutarse dentro de él por los límites de tiempo de ejecución. El patrón sano es que el plugin registre y encole, y que otro componente haga el trabajo pesado.
¿El certificado de la empresa sirve para todos los firmantes?
No. Cada persona que firma en nombre propio o como representante necesita su certificado, porque la firma identifica a un titular. Compartir un certificado destruye la atribución de autoría y complica cualquier reclamo posterior.
¿Cómo se maneja el ambiente de pruebas sin firmar de verdad?
Con un modo de simulación que devuelve una respuesta con la misma forma pero sin firma real, o con un certificado de prueba claramente identificado. Nunca con el certificado productivo.
¿Qué pasa con documentos firmados si migramos de versión de Dynamics?
Nada, siempre que el archivo firmado esté almacenado como binario inmutable y no se regenere desde una plantilla. La firma protege al archivo, no al registro del CRM.
¿Es necesario un conector personalizado?
Solo si varios flujos y aplicaciones van a consumir la misma operación. Para un único proceso, una llamada directa desde el servicio intermedio suele ser más simple de mantener.
Si tu área de TI está evaluando cómo incorporar firma electrónica al ecosistema Dynamics con las políticas corporativas ya definidas, habla con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.