ServiceNow es una de esas plataformas que parece sencilla desde fuera pero que se convierte en un laberinto en el momento en que una organización empieza a personalizarla. Lo que comienza como un catálogo de servicios o un portal de RR. HH. evoluciona rápidamente en un enredo de tablas personalizadas, políticas de interfaz, reglas de negocio, acciones de Flow Designer y endpoints REST scriptados. Nada de esto es malo. De hecho, es la razón por la que las empresas eligen ServiceNow: puedes construir prácticamente cualquier cosa.
Pero con esa flexibilidad llega la fragilidad. En el momento en que introduces lógica personalizada —especialmente lógica que depende de otra lógica— creas modos de fallo que no aparecen en la monitorización integrada y que no son visibles en la mayoría de los paneles internos. Una instancia de ServiceNow puede parecer saludable sobre el papel mientras el portal es completamente inutilizable para usuarios reales.
Ahí es donde encaja la monitorización sintética. No los “sintéticos” ligeros que ServiceNow ejecuta internamente para validar flujos de trabajo, sino la monitorización externa a nivel de navegador que simula la manera en que un usuario real interactúa con tu portal. La diferencia entre ambos es la diferencia entre comprobar el latido de un servidor y comprobar si un humano puede realmente enviar un ticket.
Los sintéticos externos captan los fallos que se originan en tus tablas personalizadas, tus scripts cliente, tus APIs scriptadas —y, en última instancia, tus decisiones de diseño. A medida que crece el número de partes móviles, la única forma fiable de confirmar que tu portal ServiceNow funciona es usar algo que se comporte como una persona real accediendo desde Internet.
Este es el alcance de este artículo: por qué las personalizaciones de ServiceNow son la raíz de la mayoría de las roturas, por qué las herramientas nativas no pueden verlo y cómo la monitorización sintética cubre esa laguna.
Por qué las personalizaciones de ServiceNow rompen la experiencia del portal
La Now Platform ofrece a las organizaciones una enorme superficie para personalizar. Y debido a que la estructura subyacente es tan modular, es fácil suponer que un pequeño cambio en un sitio no tendrá consecuencias en otro.
En realidad, casi todo en ServiceNow es relacional: las tablas personalizadas hacen referencia a otras tablas, las reglas se disparan contra clases heredadas, los scripts mutan estados de los que dependen otros scripts. Incluso elementos de UI que parecen simples en el navegador pueden estar impulsados por una pila de consultas GlideRecord, comprobaciones ACL y reglas de negocio del lado servidor.
Cuando algo va mal, rara vez parece un evento tradicional de “caída”. En su lugar, los usuarios ven síntomas como:
- Páginas que cargan lentamente hasta agotar el tiempo.
- Elementos del catálogo que se quedan congelados tras pulsar Enviar.
- Widgets que giran sin parar porque una API personalizada devolvió JSON incompleto.
- Resultados de búsqueda que de repente no devuelven nada porque una regla ajustó la herencia de ACL.
- Una página de conocimiento que funciona internamente pero falla en cuanto alguien la accede mediante SSO.
Para la infraestructura de ServiceNow, todo está “activo”. Pero para tus empleados o clientes, el portal podría estar fuera de servicio.
Estos modos de fallo no emergen de la plataforma base; emergen de cómo ha sido personalizada. Tablas, reglas, endpoints —cada uno introduce un punto débil. La monitorización sintética funciona porque no le importa el estado interno de la instancia. Solo le importa si el portal se comporta correctamente.
Los puntos ciegos en la monitorización nativa de ServiceNow
ServiceNow sí tiene monitorización “sintética” integrada en la plataforma. Pero es monitorización sintética interna: comprobaciones que se ejecutan desde dentro de la instancia, validando la ejecución de workflows, la lógica de negocio y los SLA básicos.
¿Útil? Sí. ¿Suficiente? Ni de lejos.
Los sintéticos internos viven en las mismas condiciones que el portal. No atraviesan VPNs, firewalls corporativos, geografías distintas, proveedores de identidad de terceros, capas DNS ni CDNs. No cargan un navegador, no ejecutan JavaScript ni renderizan el portal en algo que se parezca al entorno de un usuario real. No siguen journeys de múltiples pasos a través de catálogos, aprobaciones, scripts e integraciones de back-end.
Y lo más importante: no tocan lo que más se rompe: tu código personalizado. Ocurrencias comunes son:
- Un script cliente personalizado que lanza un error no desencadena una falla en el sintético interno.
- Una acción de Flow Designer que se queda estancada porque una API de terceros es lenta no disparará alertas internas.
- El endpoint de una scoped app que devuelve una carga malformada no se registrará como no saludable a menos que lo pruebes específicamente.
- Una regresión de rendimiento del lado del navegador provocada por una modificación de un widget no aparecerá en los logs del servidor.
La monitorización nativa valida la plataforma. La monitorización sintética externa valida la experiencia.
Si solo miras lo que ocurre dentro de ServiceNow, siempre estarás medio ciego.
Monitorizando tablas personalizadas: cuando la arquitectura de datos rompe la UX
Todo en ServiceNow se asienta sobre tablas, y en el momento en que una organización introduce tablas personalizadas, el grafo de dependencias crece geométricamente. Una nueva subclase de incidente, un record producer con su propio esquema, una extensión CMDB personalizada —cada uno se convierte en una nueva fuente de deriva potencial.
Los mayores problemas aparecen en el portal mucho antes de que alguien los note en la instancia.
- Una actualización de ACL que parecía inocua bloquea de repente el rellenado de un campo de referencia, lo que se traduce en un elemento del catálogo que parece “congelarse”.
- Una tabla personalizada hereda de un padre que ha sido modificado con el tiempo, y ahora una regla que depende de un campo concreto no se dispara.
- Las consultas GlideRecord se ralentizan a medida que aumentan los registros, y el portal entra en timeout aunque la instancia muestre CPU normal.
- Una dependencia entre tablas se rompe en silencio, dejando workflows atascados en “requested” sin mensajes de error.
Estos no son cortes en el sentido tradicional. Son fallos de flujo de trabajo. Y son invisibles a menos que pruebes los componentes reales del portal que dependen de esas tablas.
La monitorización sintética detecta esto porque entrelaza todo el flujo dependiente de tablas: abrir catálogo > rellenar campos > enviar > verificar el cambio de estado. Ves todo el camino, no solo las partes que ServiceNow cree que están bien.
Monitorizando reglas de negocio y scripts cliente
Las reglas son la parte más peligrosamente engañosa de ServiceNow porque se encadenan de maneras sutiles. Una regla de negocio se dispara después de un insert, lo que activa una acción de Flow Designer que actualiza un campo, que dispara un script include, que llama a una API personalizada —y de repente el simple envío de un ticket se convierte en un sistema distribuido.
Los scripts cliente crean otra modalidad de fallo: una condición errónea, una variable ausente o una nueva política de UI que entra en conflicto con una antigua. Estas fallas no aparecen en los logs como errores obvios. Aparecen en el navegador como retardos, botones congelados y comportamientos inconsistentes del formulario.
Es en el portal donde la combinación de reglas de negocio + scripts cliente se revela.
La monitorización sintética detecta:
- Una regla de negocio que provoca una consulta Glide lenta que dispara los tiempos de envío.
- Una UI policy que se dispara incorrectamente cuando campos específicos están vacíos.
- Un script cliente que se rompe solo en Chrome, no en Firefox.
- Una regla que reencamina datos a la tabla equivocada por deriva de herencia.
Los sintéticos internos de ServiceNow reportarán alegremente “todos los sistemas normales” mientras los usuarios inundan el servicio de ayuda con capturas de pantalla de widgets girando.
Las pruebas outside-in son la única manera fiable de detectar si la pila de reglas se comporta como esperas.
Monitorizando endpoints personalizados e integraciones
Los endpoints personalizados son donde un portal ServiceNow deja de ser una interfaz web simple y empieza a comportarse como una aplicación real. Las organizaciones extienden la plataforma con APIs REST scriptadas, registros de integración, acciones de Flow Designer que llaman a sistemas externos, endpoints de apps scoped y una mezcla de webhooks entrantes y salientes. Cada añadido profundiza la cadena de dependencias, y cada dependencia introduce un punto de fallo que vive fuera del entorno central de ServiceNow.
Aquí es donde se origina gran parte de las roturas del portal. Una REST scriptada que funciona mal hace que el widget que depende de ella gire indefinidamente. Una integración externa lenta hace que los envíos del catálogo queden colgados el tiempo suficiente para que los usuarios asuman que han fallado. Sistemas middleware como MuleSoft o Workato pueden imponer límites de tasa o throttling intermitente, y cuando eso sucede, ServiceNow a menudo responde con estados de error vagos que no ofrecen pistas significativas al usuario. Incluso algo tan sutil como un endpoint que devuelve JSON malformado o parcial es suficiente para romper componentes de UI de maneras que no aparecen como errores tradicionales.
Ninguno de estos problemas aparece en la monitorización nativa de ServiceNow. La plataforma solo ve su propia infraestructura, no las llamadas externas de las que dependen tus personalizaciones. Pero una prueba sintética trata esas dependencias como ciudadanos de primera clase del flujo de trabajo. Carga el widget, desencadena la llamada API, procesa la respuesta, actualiza las tablas relevantes y verifica el estado final tal como lo haría un usuario real. Esa cadena completa —la combinación de comportamiento del navegador, condiciones de red, rendimiento de endpoints y lógica de la plataforma— es lo que determina si el portal funciona realmente.
Si no pruebas continuamente todo el flujo, confías en la esperanza en lugar de en la validación. Y en un entorno ServiceNow personalizado, la esperanza no es una estrategia.
Monitorización sintética outside-in para portales ServiceNow
La monitorización sintética a nivel de navegador es fundamentalmente distinta de las comprobaciones internas de workflows. Carga tu portal exactamente como lo hace un usuario: desde una máquina real, ejecutando un navegador real, por Internet público.
Esto recrea todo el recorrido:
- Resolución DNS
- Enrutamiento por CDN
- Pasarelas corporativas o en la nube
- SSO o proveedores de identidad externos
- Ejecución de JavaScript
- Renderizado de widgets
- Llamadas API
- Actualizaciones de tablas
- Respuestas del portal
Es la diferencia entre comprobar si el motor funciona y comprobar si el coche realmente se mueve.
Para portales ServiceNow —especialmente aquellos con amplias personalizaciones— esta es la única manera de capturar la realidad.
- Si una página tarda 7 segundos en cargar, lo ves.
- Si un widget lanza un error en la consola, lo ves.
- Si un endpoint personalizado devuelve JSON malformado, la prueba falla exactamente como fallaría un usuario.
- Si una actualización de release cambia el comportamiento de un script, los tiempos de los pasos se disparan.
Los sintéticos outside-in no se preocupan de si la instancia cree estar sana. Se preocupan de si un humano puede completar la tarea.
Modelando recorridos reales del portal ServiceNow
Los portales ServiceNow no son aplicaciones lineales; son flujos ramificados. Una buena prueba sintética refleja eso. El objetivo no es hacer clic por las páginas al azar, sino validar la lógica de negocio incrustada en las tablas, reglas y endpoints que tu organización ha creado.
Una prueba adecuada refleja un flujo real:
- Autenticarse (a menudo mediante SSO).
- Abrir el portal personalizado o el catálogo de servicios.
- Buscar un elemento del catálogo que dependa de tablas personalizadas.
- Rellenar campos que desencadenen scripts cliente o políticas UI.
- Enviar, provocando reglas de negocio y llamadas a endpoints.
- Validar el registro resultante en la tabla correcta.
- Confirmar que los cambios de estado posteriores se propagan.
Esto recrea cada paso donde normalmente ocurren fallos.
Las buenas pruebas sintéticas incluyen:
- Esperas dinámicas para la carga asíncrona de widgets.
- Aserciones vinculadas a valores reales de datos, no a texto estático.
- Verificación de que el ticket llega a la tabla correcta con el estado correcto.
- Comprobaciones de que los endpoints personalizados devuelven los objetos esperados.
- Análisis de tiempos que revela reglas, scripts o integraciones lentas.
Esto no es un chequeo ligero de salud. Es una verificación comportamental full-stack de la aplicación personalizada que tu equipo ha construido sobre ServiceNow.
Detectando regresiones en upgrades y releases de ServiceNow
Las actualizaciones semestrales de ServiceNow son una fuente predecible de fallos impredecibles. Incluso con pruebas cuidadosas en preproducción, se escapan regresiones sutiles porque el comportamiento de la plataforma puede cambiar de formas que solo se hacen visibles en un entorno totalmente personalizado. Un script cliente que funcionaba perfectamente en una release puede romperse tras un cambio en el framework de UI. Un widget personalizado puede depender de dependencias que han sido refactorizadas silenciosamente. Una regla de negocio puede empezar a dispararse dos veces por un cambio en el orden de ejecución. Las acciones del Flow Designer pueden devolver estructuras de salida ligeramente diferentes, y las consultas GlideRecord pueden comportarse distinto por cambios en la indexación u optimizaciones de consulta.
No son fallos dramáticos; son fallos de segundo orden que emergen en el portal, normalmente como lentitud, comportamiento inesperado de formularios o componentes que se niegan a cargar. Y como tantas personalizaciones dependen de tablas heredadas o abstracciones de la plataforma, incluso pequeños cambios reverberan hasta que algo se rompe.
La monitorización sintética es la única forma fiable de sacar a la luz estos problemas antes de que los usuarios los experimenten. Mientras las pruebas manuales de upgrade se centran en caminos conocidos, los sintéticos validan los workflows vivos: elementos del catálogo, creación de tickets, aprobaciones, comportamientos de búsqueda y componentes dependientes de integraciones. Horas después de una actualización, los usuarios terminarán reportando qué se ha roto. La monitorización sintética te da esa visibilidad de inmediato, proporcionando una red de seguridad contra regresiones que permanece mucho tiempo después de la ventana de upgrade.
Dónde encaja Dotcom-Monitor
Dotcom-Monitor no reemplaza las herramientas internas de ServiceNow. Las complementa llenando la laguna de visibilidad entre la plataforma y la experiencia del usuario.
Con monitorización en navegador real, obtienes tiempos por paso que reflejan el rendimiento en el cliente, no solo el estado del servidor. Con monitorización de APIs, puedes validar endpoints personalizados e integraciones de forma independiente. Con ubicaciones globales, ves cómo diferentes redes y regiones interactúan con tu portal. Y con scripting multi-pasos, puedes modelar exactamente los workflows que dependen de tus tablas, reglas y endpoints personalizados.
En otras palabras: la monitorización interna mantiene la plataforma honesta, y la monitorización externa mantiene la experiencia honesta.
Conclusión
ServiceNow se vuelve potente gracias a la personalización. Se vuelve frágil por la misma razón. Cada tabla personalizada, regla y endpoint introduce nuevas maneras en que el portal puede fallar —a menudo de forma silenciosa y sin indicios en las herramientas nativas de ServiceNow.
La monitorización sintética cierra la brecha de visibilidad recreando el recorrido completo desde la perspectiva del usuario. Valida los workflows que dependen de tus estructuras de datos personalizadas. Detecta problemas de comportamiento introducidos por scripts y reglas. Expone las fallas ocultas tras llamadas API e integraciones. Y hace todo esto de forma continua, independientemente de lo saludable que la instancia crea estar.
Para organizaciones que dependen de ServiceNow como puerta de entrada —ya sea para ITSM, RR. HH., portales de clientes o aplicaciones a medida— la validación outside-in no es opcional. Es la única forma fiable de saber si el portal funciona.
Tablas. Reglas. Endpoints. Son el núcleo de tus personalizaciones ServiceNow —y el núcleo de tu estrategia de monitorización. Los sintéticos externos garantizan que se comporten como pretendías, no solo como la plataforma lo reporta.