D365 PortalCasi todas las herramientas de monitorización piden credenciales de tu sistema y entran a buscar datos. Este portal no. El flujo va en la otra dirección y eso cambia varias cosas para bien.
El problema
Dar a un tercero credenciales de tu entorno de Finance and Operations es un riesgo difícil de justificar ante seguridad, y montar tu propia infraestructura de Application Insights significa aprovisionar recursos en Azure, escribir consultas KQL y mantenerlas cuando Microsoft cambia el esquema. La primera opción es incómoda; la segunda es un proyecto.
El enfoque
El portal aprovisiona la infraestructura de telemetría por ti y te devuelve una cadena de conexión. Tú la pegas en una pantalla que D365 ya trae de serie, «Monitoring and Telemetry parameters», y a partir de ahí es tu entorno el que envía datos. El portal nunca entra en tu sistema.
- Tu entorno de D365 emite telemetría hacia el destino de tu organización.
- El destino la guarda durante el plazo de retención de tu plan.
- El portal la consulta al abrir cada pantalla y la convierte en gráficos y tablas.
Aislamiento por organización
Cada organización tiene su propia infraestructura dedicada, no una base compartida con filtros por cliente. La consecuencia práctica es que el tope de ingesta y la retención se aplican en la plataforma, no como una validación en la interfaz que alguien podría saltarse.
Dentro del portal, el acceso a los datos se resuelve siempre desde la pertenencia del usuario a la organización, nunca desde un parámetro de la petición. Un identificador de organización en una URL no da acceso a nada.
Lo que se cede a cambio
- La región de Azure se elige una vez y no se cambia: los recursos ya existen y moverlos costaría los datos ingestados.
- Hay un retardo de minutos entre que ocurre algo en D365 y aparece en el portal. No es un monitor en tiempo real.
- Si alguien pega la cadena en el entorno equivocado, esa telemetría entra igual. Por eso los entornos se registran con su identificador: es lo que permite separarla después.