Evento condicional e interrupción de tareas de usuario
El evento condicional estará escuchando como cambian los campos del formulario y en caso de que se cumpla la condición definida en el mismo, se ejecutará el camino establecido como salida del evento condicional.
Un uso típico de este evento es para interrumpir una tareas de usuario, sin que haya intervención de un usuario.
El evento condicional escuchará siempre y cuando la tarea a la cual esté asociado tenga instancias activas. Por tanto, si una instancia de proceso no se encuentra en esa tarea el evento condicional no estará escuchando al campo.
El cambio de los campos se produce al completar una tarea o al actualizar una instancia de proceso vía API. Por tanto, si se cambia un campo y guardan los cambios, el evento condicional no se enterará de ese cambio.
En caso de cumplirse la condición y si…
El evento condicional es interruptivo, entonces se cancelará la tarea y la instancia de proceso seguirá por el flujo definido luego del evento condicional.
El evento condicional es no interruptivo, entonces no se cancelará la tarea sino que se generará un camino paralelo.
Las condiciones solo se pueden definir en base a campos de formulario.
En ciertas ocasiones es necesaria la aprobación en paralelo de varias áreas de una organización a la misma vez y sobre una misma instancia. Puede ser que un Rechazo ya cancele la solicitud en su totalidad, por tanto no tendría sentido que los demás sigan teniendo la tarea para dar su aprobación cuando en realidad la misma ya está rechazada. En este caso sería útil utilizar eventos condicionales para cancelar las demás tareas una vez que una de las áreas rechazó.
Ejemplo:
Tenemos tres áreas: Área 1, Área 2 y Área 3.
Condición: Si una de las tres rechaza, se rechaza el documento en su totalidad.
Para poder emular este comportamiento, el workflow debería ser el siguiente:
En cada una de las tareas de aprobación habrá un campo Aprobación de tipo Combo donde el usuario podrá seleccionar si aprueba o rechaza el documento. Además en cada tarea se debe agregar un evento condicional que en caso de rechazo cancele las dos restantes.
Si Área 1 rechaza entonces:
Cancelar la tarea Aprobar Área 2
Cancelar la tarea Aprobar Área 3
Si Área 2 rechaza, entonces:
Cancelar la tarea Aprobar Área 1
Cancelar la tarea Aprobar Área 3
Si Área 3 rechaza:
Cancelar la tarea Aprobar Área 1
Cancelar la tarea Aprobar Área 2
Por tanto los condicionales de las tareas quedarían de la siguiente manera:
Si estableces las condiciones de este tipo de evento condicional en base a un campo de tipo Sí/No, el sistema evaluará si la condición "verdadero" o "falso" aplica ni bien llegue el flujo a las tareas en paralelo, ocasionando resultados no deseados. Recomendamos que establezcas las condiciones en base a valores en un campo de tipo combo (ejemplo: "Aceptar" y "Rechazar") y no en base a un campo de tipo Sí/No.
Por último, en el camino de salida de la compuerta inclusiva que termina en el estado final de Aprobación, debes agregar las siguientes condiciones:
Y la condición de salida de los Rechazados debería ser la condición negada:
Un uso típico de este evento es para interrumpir una tareas de usuario, sin que haya intervención de un usuario.
El evento condicional escuchará siempre y cuando la tarea a la cual esté asociado tenga instancias activas. Por tanto, si una instancia de proceso no se encuentra en esa tarea el evento condicional no estará escuchando al campo.
El cambio de los campos se produce al completar una tarea o al actualizar una instancia de proceso vía API. Por tanto, si se cambia un campo y guardan los cambios, el evento condicional no se enterará de ese cambio.
En caso de cumplirse la condición y si…
El evento condicional es interruptivo, entonces se cancelará la tarea y la instancia de proceso seguirá por el flujo definido luego del evento condicional.
El evento condicional es no interruptivo, entonces no se cancelará la tarea sino que se generará un camino paralelo.
Las condiciones solo se pueden definir en base a campos de formulario.
Casos útiles
Aprobación en paralelo
En ciertas ocasiones es necesaria la aprobación en paralelo de varias áreas de una organización a la misma vez y sobre una misma instancia. Puede ser que un Rechazo ya cancele la solicitud en su totalidad, por tanto no tendría sentido que los demás sigan teniendo la tarea para dar su aprobación cuando en realidad la misma ya está rechazada. En este caso sería útil utilizar eventos condicionales para cancelar las demás tareas una vez que una de las áreas rechazó.
Ejemplo:
Tenemos tres áreas: Área 1, Área 2 y Área 3.
Condición: Si una de las tres rechaza, se rechaza el documento en su totalidad.
Para poder emular este comportamiento, el workflow debería ser el siguiente:
En cada una de las tareas de aprobación habrá un campo Aprobación de tipo Combo donde el usuario podrá seleccionar si aprueba o rechaza el documento. Además en cada tarea se debe agregar un evento condicional que en caso de rechazo cancele las dos restantes.
Si Área 1 rechaza entonces:
Cancelar la tarea Aprobar Área 2
Cancelar la tarea Aprobar Área 3
Si Área 2 rechaza, entonces:
Cancelar la tarea Aprobar Área 1
Cancelar la tarea Aprobar Área 3
Si Área 3 rechaza:
Cancelar la tarea Aprobar Área 1
Cancelar la tarea Aprobar Área 2
Por tanto los condicionales de las tareas quedarían de la siguiente manera:
Si estableces las condiciones de este tipo de evento condicional en base a un campo de tipo Sí/No, el sistema evaluará si la condición "verdadero" o "falso" aplica ni bien llegue el flujo a las tareas en paralelo, ocasionando resultados no deseados. Recomendamos que establezcas las condiciones en base a valores en un campo de tipo combo (ejemplo: "Aceptar" y "Rechazar") y no en base a un campo de tipo Sí/No.
Por último, en el camino de salida de la compuerta inclusiva que termina en el estado final de Aprobación, debes agregar las siguientes condiciones:
Y la condición de salida de los Rechazados debería ser la condición negada:
Actualizado el: 10/04/2020
¡Gracias!