Una de las características más versátiles de la plataforma Kustomer son los flujos de trabajo. Los flujos de trabajo pueden automatizar una variedad de tareas y procesos en su plataforma mediante la creación de conjuntos de reglas que desencadenan ciertas acciones basadas en condiciones predefinidas. Aunque son increíblemente potentes, debido a la complejidad de la función, pueden producirse diversos errores y eventos no deseados si un flujo de trabajo no se ejecuta como se espera.
Hay varios tipos de errores que puede encontrar en un flujo de trabajo. Además, aunque algunos problemas de los flujos de trabajo no están relacionados específicamente con los errores, hay situaciones en las que puede haber visto que un flujo de trabajo sólo se completa parcialmente o se desplaza por el flujo incorrecto. Comprender estos tipos de problemas y cómo tenerlos en cuenta puede ayudar a que sus flujos de trabajo sean más precisos y tengan menos probabilidades de desviarse de la ruta prevista.
Acciones y condiciones del flujo de trabajo
Antes de entrar en los tipos específicos de errores de flujo de trabajo, sería importante tocar los registros de vista, que son imperativos cuando se solucionan los errores de flujo de trabajo. En un artículo del blog de hace unas semanas, discutimos el concepto de los registros de vista y cómo excavar a través de ellos con el fin de crear flujos de trabajo. Además de lo que se discute en ese artículo, los registros de los flujos de trabajo son también de vital importancia cuando se trata de solucionar cualquier problema que se encuentre relacionado con su flujo de trabajo. Para obtener más información sobre cómo acceder a los registros de vista, así como los tipos de datos que pueden hablar, puede hacer referencia a la entrada del blog vinculada anteriormente.
Nuestro centro de ayuda también contiene información relacionada con el uso de estos registros así como de los errores de flujo de trabajo para depurar cualquier problema. Aquí puede encontrar información con gran contexto sobre la solución general de errores de flujo de trabajo. En este blog seremos más detallados con respecto a los problemas específicos que puede encontrar y cómo puede verificar un problema en su flujo de trabajo, incluso si no se ha registrado como un error.
El flujo de trabajo que se muestra a continuación está diseñado para añadir una etiqueta de "Equipo de correo electrónico" a las nuevas conversaciones que llegan a través de ese canal. Además, esto también hará lo mismo para los chats con una etiqueta "Equipo de chat".
Si tenemos nuestros registros de vista activados en el momento en que el flujo de trabajo se ejecuta, podemos verificar los pasos que el flujo de trabajo recorrió al inspeccionar los registros de vista relacionados con esa interacción. En la captura de pantalla de abajo, podemos verificar que el flujo de trabajo llegó a su paso final y añadió la etiqueta a la conversación, ya que podemos ver que ambos pasos del flujo de trabajo fueron exitosos. En los casos en que tenemos un flujo de trabajo que se bifurca en diferentes caminos, también podemos verificar el camino específico que el flujo de trabajo viajó a través de los pasos resaltados en los registros.
En los casos en los que un flujo de trabajo no se ejecuta como se espera, generalmente podemos ver uno de los tres escenarios que entran en juego:
Escenario 1: El flujo de trabajo no satisface una condición
En este caso, un flujo de trabajo no llegaría al final de una de sus rutas de ramificación. Como podemos ver en este flujo de trabajo, cada rama tiene un total de dos pasos de acción que necesitaría ejecutar para completarse. En este caso, los registros del flujo de trabajo sólo muestran un paso de acción como completado. Compruebe las condiciones por las que debería haber pasado el flujo de trabajo y verifique dónde podría haber una discrepancia con los datos enviados a través de los registros de la vista. En el caso de los flujos de trabajo más grandes, ésta sería la rama de condiciones directamente después del último paso de acción completado.
Escenario 2: El flujo de trabajo se desplaza por la ruta incorrecta del flujo de trabajo
En algunos casos, al inspeccionar los registros de la vista del flujo de trabajo, puede observar que el flujo de trabajo recorre una ruta no deseada. Esto puede deberse a una de estas dos razones:
- La primera ruta (prevista) del flujo de trabajo no se satisfizo, por lo que el flujo de trabajo recorrió la siguiente ruta disponible.
- El flujo de trabajo satisface varias condiciones en la misma rama de condiciones. En estos casos, el flujo de trabajo se desplazará por la condición que satisfaga más cerca de la izquierda de la rama de condiciones, que podría no ser la rama por la que usted pretendía que se desplazara.
La solución para ambos sería más o menos la misma. Asegurar que en un escenario específico, la rama de condición de un flujo de trabajo tenga opciones diametralmente opuestas. Por ejemplo, si una rama de condición busca que el único canal de la conversación sea el correo electrónico o el chat, nunca habrá un momento en el que una conversación pueda satisfacer más de una rama. Para las ramas en las que son posibles múltiples satisfacciones, debes asegurarte de que la rama que sirve como opción "dominante" es la más cercana al lado izquierdo de la rama.
Escenario 3: El flujo de trabajo escribe la información incorrecta a través de una configuración errónea
También sería posible que un flujo de trabajo se ejecutara con éxito, pero que posiblemente escribiera los datos incorrectos en un atributo o que aprovechara los datos correctos en un paso de condición del flujo de trabajo. Esto también puede ocurrir por una de dos razones:
- La fuente de los datos no es la que usted esperaba inicialmente.
- El atributo del flujo de trabajo utilizado para satisfacer una condición o escribir en un campo está vinculado incorrectamente. Por ejemplo, al verificar el ID de una conversación en un flujo de trabajo, la condición podría estar configurada para extraer accidentalmente el ID de un cliente.
Para resolver estos problemas, usted querrá asegurarse de que el conjunto de datos a rellenar en un atributo o verificar en una condición está vinculado apropiadamente a través de la verificación del paso y el atributo al que los datos están vinculados. Esto se puede hacer muy fácilmente a través de la vista de código de los datos como se ve a continuación.
Además, también querrá asegurarse de que los datos en sí son los esperados de la fuente de la que los extrae mediante estos mismos pasos.
Errores de la API (Ruta/Datos/Tipo de datos)
Dentro de los flujos de trabajo, también tiene la posibilidad de crear pasos de acción que pueden llamar a la API Kustomer o a otras API externas. Esto puede ser increíblemente útil cuando se necesita verificar la información de otro sistema o realizar otras operaciones fuera del ámbito tradicional de los pasos de acción de los flujos de trabajo normales. Esto hace que nuestra función de flujos de trabajo sea exponencialmente más potente, pero como todo lo que hemos discutido hasta ahora, las cosas pueden fallar. Por esta razón, valdría la pena nuestro tiempo para repasar los tipos de errores de la API que puede recibir en sus flujos de trabajo.
A continuación se muestra un flujo de trabajo que utiliza un paso JSON de la API REST para realizar una llamada al punto final de la API de actualización de conversaciones, añadiendo una etiqueta de "Conversación completa" a las conversaciones que se han marcado como realizadas
Los errores de la API en los flujos de trabajo pueden estar un poco más ocultos que muchos errores de los flujos de trabajo tradicionales, ya que se encuentran dentro de la propia llamada a la API y no en el flujo de trabajo. Además, los pasos de acción de la llamada a la API pueden aparecer como ejecutados con éxito incluso si la configuración prevista no está ocurriendo. Al ver los registros, haga clic en el paso de la API. La parte de salida de los registros le mostrará los resultados de la llamada a la API.
El hecho de que esta llamada a la API haya dado lugar a un statusCode de 200 es estupendo, ya que generalmente indica que se ha realizado una llamada con éxito. Diferentes statusCodes se mostrarán en esta salida relacionados con un problema más específico que la llamada a la API podría haber encontrado. Por ejemplo, un statusCode de 401 indica que hubo un problema con la autorización de la llamada, lo que significa que probablemente querrá comprobar la clave de la API que se está utilizando para hacer la llamada. Un error 400 podría indicar que algún aspecto de la llamada no está formateado correctamente, como los datos o la URL. Antes de continuar con la resolución de problemas, asegúrese de que todo el código relacionado con la llamada es correcto según la documentación de la API. Para más información sobre los códigos de estado que puede encontrar con nuestra API, puede ver nuestra documentación sobre el tema aquí.
Otro tipo de problema que puede encontrar es que la llamada a la API no procese su solicitud como se espera. Por ejemplo, si está intentando actualizar un atributo de la conversación a través de esta llamada de la API, la llamada se mostrará como exitosa incluso si la parte de datos de la carga útil de la llamada de la API está vacía. Esto se debe a que la API ha sido capaz de comunicarse con el servidor previsto. Los mismos registros anteriores podrían decirle exactamente lo que se configuró a través de la llamada y estos tipos de problemas pueden ser resueltos a partir de ahí.
Flujos de trabajo recursivos/en bucle
Otro tipo de error que puede encontrar en su flujo de trabajo es que se ejecute continuamente. Esto es lo que comúnmente llamamos un flujo de trabajo recursivo. Por ejemplo, si usted tiene un flujo de trabajo que se activa en una actualización de la conversación para actualizar otro atributo en una conversación, este tipo de acción de salida también se consideraría una actualización de la conversación, lo que provocaría que el flujo de trabajo se ejecutara de nuevo.
Un ejemplo de esto sería un flujo de trabajo que crea una nota en una conversación cuando la conversación se actualiza. Dado que la no creación es también una actualización de la conversación, esto desencadenaría que el flujo de trabajo se ejecutara de nuevo, creando una nueva nota, desencadenando el flujo de trabajo de nuevo, y así sucesivamente.
Si encuentra que un flujo de trabajo se ejecuta involuntariamente varias veces, lo primero que debe hacer es desactivar el flujo de trabajo para cortar el bucle. A partir de ahí, recomendamos crear condiciones para evitar que el flujo de trabajo se ejecute posteriormente. Por ejemplo, cuando se actualiza un atributo en una nueva conversación, se podría añadir una condición para verificar si el atributo en el momento de la actualización está actualmente en blanco. Esto le permitirá actualizar el atributo una vez, y evitará que el flujo de trabajo se ejecute más veces, ya que el atributo tendrá un valor cuando intente ejecutarse de nuevo.
Aunque los flujos de trabajo son potentes, a menudo pueden resultar confusos, especialmente para una persona que no haya creado inicialmente un flujo de trabajo. Al comprender los diferentes tipos de problemas que podrían afectar al funcionamiento previsto de un flujo de trabajo, puede armarse mejor para encontrar las interrupciones en el flujo de trabajo que pueden impedir que funcione como se pretende.
Si tiene alguna pregunta general sobre cómo entender mejor los flujos de trabajo en su conjunto, o necesita ayuda para depurar un problema, no dude en ponerse en contacto con support@kustomer.com o visite nuestra base de conocimientos en help.kustomer.com.
Kustomer University es otro gran recurso, con vídeos y tutoriales para ayudarte a utilizar mejor todo lo que ofrece Kustomer .
