Cómo Dynamics 365, Power Platform, Azure y Microsoft 365 encajan entre sí, cómo diseñar un esquema Dataverse que no te encierre, cuándo usar Power Automate frente a una integración Azure personalizada, cómo migrar datos sin perder una semana en limpieza, y cómo conectar la identity de todo tu stack con Entra ID. Escrita desde implementaciones reales, no desde resúmenes de la documentación Microsoft.
Microsoft vende muchos productos que se solapan de formas confusas. Los nombres cambian cada pocos años, los bundles de licencias incluyen capacidades en combinaciones no intuitivas, y la documentación es vasta pero organizada por productos individuales en lugar de por los flujos de trabajo que soportan. Lo que sigue es lo contrario: cómo encajan las piezas en la práctica, las decisiones de diseño que importan y los errores que cuestan más tiempo corregir después.
El stack comercial Microsoft tiene cuatro capas diferenciadas, y cada una depende de la que tiene debajo. Entender en qué capa estás trabajando te indica qué producto usar y qué restricciones aplican.
Las implicaciones son prácticas. Dynamics 365 corre sobre Dataverse y lo incluye en la licencia. Power Apps y Power Automate también pueden conectarse a Dataverse de forma independiente, sin Dynamics. Azure está por debajo de todo y gestiona la identity (a través de Entra ID), las integraciones que van más allá de lo que Power Automate soporta, y cualquier cómputo que Microsoft 365 o Power Platform no pueden proveer.
Microsoft 365 incluye SharePoint, OneDrive, Teams, Exchange y las apps Office. No incluye Dynamics 365 ni un entorno Dataverse por defecto. Los dos ecosistemas comparten identity a través de Entra ID pero son líneas de licencia separadas. La mayoría de la confusión al definir el alcance viene de confundirlos.
Dataverse es la base de datos sobre la que corren Dynamics 365 y Power Platform. Es un almacén estructurado en la nube que entiende conceptos empresariales: tablas, relaciones, campos de lookup, reglas de negocio y roles de seguridad. No es una base de datos relacional de propósito general, y no es adecuada para cargas de trabajo con escrituras de alto volumen. Donde destaca es conservando registros empresariales, aplicando control de acceso a nivel de fila y columna, y exponiendo datos a flujos Power Automate, Power Apps y formularios Dynamics sin código personalizado.
El diseño de esquema en Dataverse es donde la mayoría de implementaciones se preparan para el éxito o crean años de retrabajo. Algunos principios que se sostienen en cada proyecto que hemos realizado:
xyz_) previene colisiones de nombres con las actualizaciones de Microsoft. Apícalo desde el primer día; el retrofitting es costoso.Sobre los entornos. Los entornos Dataverse son instancias aisladas con bases de datos separadas. Producción, UAT y desarrollo deben ser cada uno un entorno separado. Promover paquetes de solución entre entornos (no copiar datos) es el patrón de despliegue correcto. Muchos equipos omiten esto al principio y lo pagan cuando un cambio de desarrollo corrompe el esquema de producción.
Dynamics 365 viene en varias aplicaciones: Sales, Customer Service, Field Service, Finance, Supply Chain y otras. Los dos puntos de entrada más comunes para empresas en crecimiento son Sales (pipeline y CRM) y Customer Service (gestión de casos y soporte). Comparten el mismo backend Dataverse y pueden desplegarse juntos, pero cada uno tiene un modelo de datos distinto y una lógica de proceso empresarial específica.
Sales te da los objetos CRM estándar, la conversión de Lead a Opportunity, el seguimiento de actividades (llamadas, emails, reuniones) y la previsión del pipeline. El trabajo de configuración en una implementación típica de Sales incluye: personalizar los formularios de Lead y Opportunity para adaptarlos a tu proceso de ventas real, configurar el flujo de proceso empresarial que gobierna la progresión de etapas, configurar la sincronización de email y calendario con Exchange, y mapear el modelo de datos del CRM legacy o las hojas de cálculo a la estructura de entidades Dynamics.
El error más común es aplicar el proceso de ventas Dynamics predeterminado a una empresa con un modelo diferente y luego pelear con la herramienta durante meses. El flujo de proceso empresarial es configurable; el enfoque correcto es modelar tus etapas reales y campos obligatorios, luego dejar que Dynamics los aplique en lugar de construir workarounds en hojas de cálculo paralelas.
Customer Service está construido alrededor de la entidad Case: un registro de un problema de cliente desde la recepción hasta la resolución. La configuración incluye reglas de enrutamiento (qué casos van a qué colas y agentes), definiciones de SLA, la base de conocimiento y los formularios del agente. Customer Service también se integra con Teams para la colaboración de agentes y con Omnichannel for Customer Service si necesitas enrutar chat en vivo, email y voz a través de la misma interfaz.
La decisión de diseño crítica es cómo los Cases se relacionan con Accounts y Contacts. En la mayoría de implementaciones, un Case pertenece a un Contact y está asociado al Account de ese Contact. Si tu soporte es B2B (una empresa, muchos contactos), necesitas asegurarte de que la vista Account muestra todos los Cases de todos los contactos de la empresa, no solo el que abrió cada ticket.
Power Automate es donde proviene la mayoría del ahorro de tiempo en una implementación Microsoft, y también donde se crea más deuda técnica. Un flujo bien diseñado es mantenible, testeable y gestiona errores. Uno mal diseñado es un enredo de condiciones y acciones scope que nadie puede leer seis meses después.
Algunas reglas de diseño que dan resultado siempre:
Power Apps es un builder de aplicaciones low-code que se conecta a Dataverse, SharePoint, SQL y cientos de otras fuentes de datos. Produce dos tipos de apps: canvas apps (tú diseñas cada pantalla) y model-driven apps (la app genera pantallas desde tu esquema Dataverse). Dynamics 365 en sí mismo es una model-driven app; la mayoría de las herramientas internas personalizadas son canvas apps.
Las canvas apps son la elección correcta cuando: el diseño de pantalla necesita ser preciso, estás construyendo sobre datos no Dataverse, o los usuarios están en móvil y necesitan una interfaz personalizada. Las model-driven apps son mejores cuando: tienes un esquema Dataverse complejo con muchas tablas relacionadas, necesitas las vistas, formularios y flujos de proceso empresarial integrados, o estás extendiendo Dynamics 365 en sí mismo.
La restricción a conocer antes de empezar: las canvas apps no son un reemplazo para una aplicación web cuando necesitas lógica de negocio compleja, alta concurrencia de usuarios o control de acceso sofisticado en la capa UI. Funcionan bien para 5 a 50 usuarios internos haciendo introducción y recuperación de datos estructurados. Más allá de eso, normalmente estás mejor servido con una app web ligera sobre una API Azure.
Sobre las licencias. Las licencias Power Apps son por usuario al mes. Una canvas app que solo lee datos de SharePoint y Microsoft 365 no requiere una licencia premium. Una canvas app que se conecta a Dataverse o APIs externas sí. Esta distinción ahorra costes significativos a escala, así que mapea tus fuentes de datos antes de comprar.
Power Automate gestiona la mayoría de la automatización de flujos de trabajo. Cuando necesitas algo que no puede hacer de forma fiable, Azure es la respuesta. Los casos en que usamos Azure en lugar de Power Automate:
Logic Apps y Power Automate comparten la misma biblioteca de conectores y el mismo lenguaje de expresiones. Logic Apps es la elección correcta cuando necesitas que la integración corra en una región Azure específica, requieres SLAs enterprise, necesitas integrar en un pipeline de despliegue Azure DevOps, o tienes requisitos de cumplimiento que impiden almacenar datos en el tenant cloud Power Platform.
Entra ID (antes Azure Active Directory) es la columna vertebral de identity del stack comercial Microsoft. Cada usuario de Microsoft 365 y Dynamics 365 se autentica a través de él. Si quieres single sign-on en todas tus herramientas SaaS, políticas de acceso condicional o acceso de invitados para colaboradores externos, Entra es donde lo configuras.
El trabajo práctico en una implementación típica cubre tres áreas. Primero, verificar que todos tus usuarios están provisionados en Entra y que las licencias están asignadas correctamente, porque un usuario mal configurado encontrará errores confusos en Teams, SharePoint y Dynamics. Segundo, configurar las políticas de acceso condicional: requerir autenticación múltiple, restringir el acceso desde dispositivos no administrados para apps sensibles y bloquear el acceso desde ubicaciones de alto riesgo. Tercero, configurar las enterprise applications para cualquier SaaS no Microsoft que soporte federación SAML u OIDC, de modo que los usuarios accedan a todo con sus credenciales Microsoft.
Para empresas con usuarios invitados (contratistas, clientes, socios), las cuentas de invitado Entra B2B permiten invitar identidades externas a canales Teams específicos, sitios SharePoint o incluso vistas Dynamics concretas, sin darles acceso completo de empleado. El límite de permisos se aplica a nivel Entra, no a nivel de aplicación, lo que es más fiable.
Microsoft 365 es la capa de colaboración sobre la que la mayoría de empresas ya opera. El trabajo que hacemos aquí en un proyecto de implementación Microsoft tiene menos que ver con desplegar Teams y más con hacerlo útil en relación a Dynamics y Power Platform.
Las dos integraciones que generan más valor son la app Dynamics 365 para Teams y los flujos Power Automate que llevan eventos Dataverse a canales Teams. La app Dynamics permite a los equipos de ventas y soporte ver y editar registros CRM sin salir de Teams, lo que importa para empresas donde Teams es la superficie de comunicación principal. El patrón de notificaciones en canales significa que un nuevo lead, un trato cerrado o una escalada de caso pueden aparecer como una tarjeta en el canal Teams adecuado con el contexto relevante, reemplazando la cadena manual de emails.
SharePoint merece una nota específica. SharePoint es excelente para almacenamiento de documentos, contenido de intranet y listas estructuradas. Es un mal sustituto de Dataverse cuando necesitas datos relacionales, seguridad a nivel de fila o más de unos pocos miles de elementos en una lista. Vemos muchos equipos intentar gestionar sus procesos empresariales en listas SharePoint porque ya tienen la licencia, y luego chocar con los límites de columnas, el umbral de 5.000 elementos en la vista y la falta de relaciones calculadas. Dataverse es la herramienta correcta para datos empresariales estructurados; SharePoint es la herramienta correcta para documentos y contenido.
Power BI se conecta a Dataverse, SharePoint, SQL, Excel y la mayoría de APIs cloud, y muestra datos en dashboards que pueden incrustarse en Teams, SharePoint o una URL pública. En una implementación del stack Microsoft, el trabajo de reporting cubre típicamente tres capas: dashboards operacionales para visibilidad diaria (pipeline por etapa, casos abiertos por equipo), informes de gestión (win rate, tiempo de resolución, uso de licencias) y resúmenes ejecutivos que agregan múltiples fuentes de datos.
La decisión de diseño más importante es si usar el modo DirectQuery o Import. El modo Import carga datos en el motor en memoria de Power BI y los actualiza según una planificación, típicamente una o varias veces al día. Es más rápido para la mayoría de tipos de consultas y maneja mejor los datasets más grandes. DirectQuery envía consultas directamente a la fuente al cargar el informe, lo que proporciona datos en vivo pero es más lento y pone más carga sobre Dataverse. Para datos Dynamics 365 que no necesitan ser en tiempo real al minuto, Import con actualización horaria suele ser el mejor equilibrio.
Sobre la seguridad a nivel de fila. Si tus informes Power BI muestran datos que distintos usuarios solo deben ver en parte (los comerciales ven su propio pipeline, los managers ven su equipo, los directores ven todo), configura la seguridad a nivel de fila en el dataset Power BI, no creando informes separados. Un informe con seguridad a nivel de fila aplicada al dataset es mantenible; veinte informes variantes para distintos roles no lo son.
La migración de datos es donde la mayoría de los calendarios de implementación Microsoft se retrasan, y casi siempre porque los datos fuente estaban peor de lo que nadie pensaba. La conversación estándar de discovery con un cliente sobre sus datos CRM legacy o de hoja de cálculo tiende a revelar: registros Contact duplicados con grafias diferentes, números de teléfono almacenados en múltiples formatos, valores de etapa de operación que se mapean vagamente al nuevo proceso de ventas, y archivos adjuntos que no están referenciados por ningún campo de registro.
Un proceso realista de migración de datos tiene cinco pasos. Primero, una extracción de los datos fuente en su forma cruda, sin limpieza manual. Segundo, un pase de profiling: contar los nulos, los duplicados, las violaciones de formato y las brechas de integridad referencial. Tercero, un documento de mapeo que dice, para cada campo fuente, a qué campo Dataverse se mapea, qué transformación aplica y qué hacer con valores que no se mapean limpiamente. Cuarto, una importación de prueba en un entorno sandbox, validada contra los números del perfil. Quinto, la importación de producción con una captura delta para cualquier registro que cambió durante la ventana de migración.
La herramienta que usamos para la mayoría de las migraciones Dataverse es la función de importación de datos Dataverse para datos planos sencillos, y Azure Data Factory para migraciones multi-tabla más complejas o para datos que necesitan una transformación significativa antes de cargarse. Power Query (que está dentro tanto de Power BI como de Power Automate) maneja el trabajo de transformación más ligero.
La fase más importante de proteger es el diseño del esquema. Los cambios en el modelo de entidades Dataverse después de que los datos hayan sido migrados requieren remapeo, reimportación y repetición de pruebas en los flujos y formularios afectados. Dos semanas de trabajo cuidadoso en el esquema al inicio ahorra cuatro semanas de retrabajo después. Cada proyecto de implementación que hemos realizado dentro del presupuesto lo hizo porque el esquema estaba bloqueado antes de comenzar la configuración.
El user acceptance testing es la otra fase que se comprime cuando los calendarios se retrasan. El UAT no es solo una casilla antes del go-live; es el último punto donde un flujo de proceso empresarial mal configurado o una integración rota pueden detectarse antes de que afecte datos de clientes reales. Construimos los scripts UAT a partir de los mapas de procesos creados durante el scoping, de modo que los usuarios prueban escenarios reales, no improvisan.
Una breve lista de los patrones que consistentemente hacen que los proyectos se atasquen o fallen:
Ese es todo el método. Cuando quieras aplicarlo a tu organización, el siguiente paso es un audit gratuito: una revisión real de tu stack Microsoft actual, tus procesos y dónde están las brechas, en unos dos días, sin ningún compromiso.
Un audit gratuito de tu stack Microsoft actual, los hallazgos escritos y un alcance fijo para construir lo que importa. Hallazgos en 48 horas.
Solicitar audit Microsoft gratuito