Un cliente cuenta que la misma solicitud llegó dos veces al equipo equivocado. La regla de enrutamiento parece correcta, todos los agentes figuran disponibles y nadie puede mostrar en qué punto cambió la decisión. Ese es el momento en que hace falta un registro de ruta.
Si el equipo dependía de los diagnósticos de enrutamiento unificado de Dynamics 365, no intentes reconstruir la pantalla antigua con capturas y notas manuales. Microsoft indica que la función se retiró el 31 de marzo de 2026 y recomienda los diagnósticos de conversación en Azure Application Insights. El reemplazo práctico consiste en conectar la ruta de evidencia, ejecutar una conversación conocida, revisar por separado el enrutamiento y la asignación, y nombrar a una persona responsable de los registros.
Empieza por la pregunta que debe responder el registro
No comiences exportando todos los eventos posibles. Formula una pregunta operativa. ¿Por qué esta conversación entró en la cola incorrecta? ¿Por qué ningún agente recibió la oferta de trabajo? ¿Por qué falló una transferencia? ¿Por qué un cambio de capacidad alteró la asignación?
- 1Define el camino esperadoRegistra canal, cola, habilidad, prioridad, estado del agente y propietario previsto.
- 2Conecta la evidenciaRelaciona entorno administrado, Application Insights, responsables de acceso y retención.
- 3Ejecuta una prueba conocidaUsa identificadores permitidos y una conversación controlada que represente el fallo.
- 4Separa ruta y asignaciónConfirma primero la cola y después elegibilidad, capacidad, oferta y propiedad.
- 5Cambia y repiteAjusta la configuración mínima y compara el nuevo recibo con el original.
Anota la pregunta junto a un registro de prueba estable y una ventana de tiempo. Conserva el canal, la cola, la habilidad requerida, la prioridad, el estado esperado del agente y el resultado previsto. Esa base vuelve legible la evidencia y la conecta con la auditoría de reglas de enrutamiento, en lugar de crear otro proyecto de supervisión aislado.
El aviso oficial de Microsoft delimita el producto con claridad. Los diagnósticos de enrutamiento unificado ya no son la opción compatible. Los diagnósticos de conversación en Application Insights sí lo son. La sustitución debe demostrar que un elemento de trabajo real recorrió el camino previsto y que llegó la evidencia necesaria para explicar la decisión.
Conecta la ruta de evidencia
La guía de configuración indica que el entorno de Customer Service se conecta a una instancia de Azure Application Insights mediante exportación de datos. El entorno debe ser administrado. Quien lo configura necesita acceso adecuado a Azure y quien consulta los datos, al menos permiso de lectura. Solo se admite una configuración de exportación de Customer Service a Application Insights por entorno.
La ingesta tiene coste, así que estima volumen y retención. Limita el acceso porque la evidencia puede revelar identificadores de clientes, acciones de empleados, colas y disponibilidad. Aplica los mismos controles de seguridad que al historial del cliente.
Ejecuta una conversación conocida
Elige una prueba que represente un fallo real sin usar contenido sensible en vivo. Dale un canal, una cola, una habilidad, una prioridad, un estado de agente y un propietario esperado. Registra la hora de inicio y los identificadores que tu política permita conservar. Después envía el elemento por el camino normal.
No cambies varias reglas durante la prueba. Si la disponibilidad puede influir, confirma el estado con la auditoría de disponibilidad de agentes. Si el problema puede estar en la capacidad, compara la configuración con la guía de perfiles de capacidad.
| Punto de evidencia | Responsable | Qué registrar | Cuándo detenerse |
|---|---|---|---|
| Entrada de prueba | Líder de operaciones | Canal, cola, habilidad, prioridad y propietario esperado | El camino esperado no está claro |
| Conexión de exportación | Administrador de Dynamics | Entorno y destino de Application Insights | No se puede demostrar el destino |
| Búsqueda de trazas | Lector de Azure | Ventana temporal e identificadores permitidos | No se puede aislar la prueba |
| Resultado de enrutamiento | Propietario de rutas | Decisión de cola y versión de regla | La cola cambia sin explicación |
| Resultado de asignación | Responsable de carga | Disponibilidad, capacidad, oferta y aceptación | No se puede reconstruir la propiedad |
| Aceptación | Propietario del servicio | Corrección, repetición y decisión de supervisión | Nadie acepta el resultado |
Lee por separado el enrutamiento y la asignación
Una conversación puede entrar en la cola correcta y llegar a la persona equivocada. También puede desviarse antes de que empiece la asignación. Mantén separadas esas preguntas.
Primero sigue la entrada, la clasificación y la ruta hacia una cola. Compara los atributos reales con la versión de reglas activa en ese momento. Después revisa la asignación, incluidos agentes elegibles, habilidades, presencia, capacidad, ofertas, rechazo o tiempo agotado y propiedad final. La guía de rechazos y tiempos agotados explica por qué una oferta no equivale a que el agente sea dueño de la conversación.
No inventes la evidencia que falta. Un resultado vacío puede indicar una mala exportación, acceso insuficiente o el entorno equivocado. Confirma la ruta antes de cambiar producción.
La bandeja compartida de clientes muestra propiedad e historial, pero no sustituye la telemetría. Úsala para entender el impacto y los diagnósticos para explicar la decisión.
Cambia una cosa y repite la prueba
Cuando la evidencia señale una regla, habilidad, pertenencia a una cola, presencia o capacidad, cambia el elemento mínimo relevante. Registra quién lo aprobó y cómo volver atrás. Repite la misma prueba con la misma expectativa.
Compara ambos recibos. La prueba corregida debe llegar a la cola y al propietario previstos y el registro debe explicar el motivo. Si solo funciona por intervención manual, el problema no está resuelto.
Retira la evidencia antigua con cuidado
El aviso de Microsoft enlaza un proceso aparte para eliminar los datos antiguos de diagnósticos de Dataverse. No borres la historia solo porque desapareció la función. Aplica la política de retención, conserva lo necesario para investigaciones abiertas, acepta primero la ruta de Application Insights y documenta qué se eliminó y quién lo hizo.
El objetivo es explicar una decisión desde la solicitud hasta el propietario final. Usa ese estándar al cambiar reglas, capacidad o flujos.
Preguntas frecuentes
Siguen disponibles los diagnósticos de enrutamiento unificado
Microsoft indica que la función se retiró el 31 de marzo de 2026. Utiliza diagnósticos de conversación en Azure Application Insights como ruta compatible.
Corrigen los diagnósticos el problema de forma automática
No. Registran eventos del ciclo de vida. Un administrador o responsable de operaciones debe interpretar la traza, aplicar un cambio controlado y repetir la misma ruta.
Qué debe probar primero un equipo
Empieza con un problema reciente y repetible cuya cola y propietario esperados sean conocidos. No hagas un cambio amplio en producción hasta poder aislar la prueba y explicar el enrutamiento y la asignación.
¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
De la lectura a la acción
¿Quieres aplicar estas ideas en tu negocio?
Déjanos tus datos. Tendremos en cuenta el artículo que estás leyendo y empezaremos con una respuesta útil para tu equipo.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes
