Flow Designer vs Workflow Editor: cuando usar cada uno

En proyectos nuevos, la recomendacion es directa: Flow Designer por defecto. Workflow Editor sigue existiendo por compatibilidad y porque algunos patrones muy especificos todavia se resuelven mejor ahi, pero la inversion de ServiceNow esta claramente en Flow Designer.

Donde Flow Designer gana

• Sintaxis declarativa que cualquier funcional puede leer
• Reutilizacion real via subflujos con inputs y outputs tipados
• IntegrationHub nativo con cientos de spokes sin escribir codigo
• Mejor manejo de errores y compensacion
• Historial visual de ejecuciones facil de depurar

Donde Workflow Editor todavia aparece

Flujos de aprobacion en Service Catalog muy arraigados en instancias legacy, algunos patrones de graphical workflow con logica muy condicional y proyectos con requisitos de compatibilidad hacia atras con integraciones viejas. En estos casos, mantener Workflow Editor puede ser pragmatico; empezar ahi en un proyecto nuevo no tiene justificacion.

Criterios de decision en proyectos nuevos

Usamos tres criterios. Primero, compatibilidad: si el caso toca areas donde el producto sigue exigiendo Workflow Editor (algunas integraciones legacy), no queda de otra. Segundo, complejidad: si el flujo tiene logica condicional profunda que se resuelve mejor con subflujos, Flow Designer escala mejor. Tercero, mantenibilidad: si el cliente quiere que funcionales operen el flujo sin desarrollador, Flow Designer es la unica respuesta razonable.

Migracion de workflows existentes

No migres por migrar. El costo no se justifica si el workflow actual esta estable y no va a cambiar. Migra cuando el workflow necesita evolucionar, cuando introduces IntegrationHub, o cuando tienes que entrenar a un equipo nuevo que no quiere aprender Workflow Editor. La migracion oportunista es mas barata que el big bang.