Cuando uno viene de pelearse con múltiples Workflows en SharePoint Designer 2010, tiene unas ganas tremendas de trabajar con los Workflows de SharePoint Designer 2013 y sus flamantes nuevas características tales como: Bucles, llamadas a Web Services, Variables de tipo “Diccionario”, Invocación interna a otros Workflows… ¡Y es cierto! SPD 2013 viene con muchas características nuevas de las que podemos sacar buen provecho en nuestros nuevos flujos, sin embargo… ¡¡ALERTA!! No empieces a implantar un flujo en SPD 2013 sin haber analizado previamente los requerimientos que necesita tu Workflow, porque, desgraciadamente, SPD 2013 también tiene pérdidas funcionales respecto SPD 2010. Por increíble que suene, es cierto: Por un lado SPD 2013 tiene nuevas y atractivas funcionalidades, pero por otro pierde algunas también muy básicas y en ocasiones imprescindibles, que te pueden llevar al arrepentimiento de haberte embarcado en la aventura de los flujos en 2013.

En este post analizaremos todas esas carencias (incoherencias según mi punto de vista), y como se podrían llegar a corregir (alguna de ellas). Sobre todo ten bien presente esto: No todos los nuevos Workflows los debes implantar en 2013, algunos serán posibles únicamente en modo 2010. Recordad que SPD 2013 permite trabajar con flujos de tipo 2013 o 2010, según elija el usuario. Quizás hoy entiendas realmente el por qué.

image

1.- No existe la posibilidad de crear un “Impersonation step”: Cuando un usuario lanza un workflow, este se ejecuta con las credenciales del usuario iniciador. Si se desea realizar tareas con permisos de otro usuario concreto, en 2010 teníamos la opción de crear “impersonation steps”. Estos pasos se ejecutaban con las creedenciales del usuario que había implantado el flujo (se debía vigilar que si el usuario dejaba la empresa y se borraba del AD, previamente se había cambiado los permisos de estos “impersonation steps” a un usuario distinto). Pues bien, esto en 2013 ya no existe. No hay posibilidad de simularlo. Simplemente los permisos de un flujo serán siempre los del usuario que lo ejecute.

2.- No se puede modificar la seguridad de un elemento (ítem o documento): Esta es una carencia muy grave, pues muchos flujos requieren este tipo de acciones. En 2010 sólo se podía hacer mediante un “impersonation step”, pero como en 2013 no existen… tampoco se pueden utilizar las acciones que sí teníamos en 2010:  “Add List Item Permissions”, “Inherit List Item Parent Permissions”, “Remove List Item Permissions” y “Replace List Item Permissions”.

image

Entonces, si tengo un workflow en 2013 que necesita modificar los permisos de un documento en una biblioteca o de un ítem en una lista. ¿Cómo puedo hacerlo? Agarraos fuerte: Invocando un flujo de SharePoint 2010 desde el flujo de 2013

3.- Wait for a field change extremadamente limitado: En muchas ocasiones, para aseguraros de que vuestro flujo se ejecuta una única vez, o una cierta parte se ejecuta únicamente cuando se ha informado correctamente un campo del formulario del documento/item original, la única acción de SPD que os puede ayudar es la de “Wait for a field change”. Esta acción permite que el flujo se quede “a la espera” de que el valor de un campo indicado concreto cambie para seguir. Imaginaos un flujo con estados, por ejemplo. El estado inicial puede ser “Pending”, y podría cambiar a “Approved” o “Rejected” en función de la decisión del validador. Bien, en 2010 podíamos utilizar “Wait for Approval Status to not equal Pending”, pero en 2013 no se puede, porque no existe el “to not equal”, la única opción aquí es “to equal”. Esto que a simple vista puede parecer una tontería, puede invalidar un flujo por completo realizado en 2013. Observad las diferencias:

En SPD 2010:

image

En SPD 2013:

image

Como veis “to equal” no permite ninguna sustitución, limitando enormemente esta potente acción de 2010. Uno podría pensar que se podría compensar usando un bucle que se ejecutara continuamente hasta que “Approval Status” not equals “Pending”, pero, amigo mío, eso implicaría tener el flujo continuamente en ejecución (consumiendo recursos de servidor), y si tu empresa es grande y tiene 600 flujos (o 60.000) recorriendo bucles constantemente, más vale que te apartes lejos antes de “sentir” la explosión.

Ya pensando a la desesperada, podrías llegar a pensar: “pongo un flag”. Un flujo en 2010 que sí tenga el “Wait for Approval Status to not equal pending” que cuando cumpla la condición modifique un campo (flag) del ítem a un valor establecido, y otro flujo en 2013 esperando que ese campo (flag) cambie a ese valor establecido (rocambolesco, eh!?), pues bien, en caso de que tengais el “content approval” de una biblioteca/lista activado tampoco os va a funcionar, porque esa característica incluye en sí misma que una modificación en un campo del ítem invalida la validación previa, de forma que si alguien valida un documento y el WF 2010 cambia el flag de 0 a 1, automáticamente el documento se “desvalida” y vuelve a quedar a “Pending”, así que cuando el WF 2013 se active porque el flag ha cambiado de 0 a 1, el documento ya no estará validado (mas rocambolesco todavía!!). Total, que no existe una solución medianamente “polite” a esta encrucijada (¡Bravo Microsoft!). Personalmente he tenido que tirar a la basura flujos de 2013 por este motivo, y rehacerlos de nuevo en 2010.

4.- Lookups con campos adicionales: En SPD 2010, si tu tenías una lista donde habías definido algún campo de lookup con campos adicionales de la lista origen, estos campos eran accesibles desde SPD en un Workfow asociado a esta lista. En SP 2013 únicamente puedes acceder al campo base, pero no a los relacionados. Otra pérdida insustituible.

En SPD 2010:

image

En SP 2013:

image

Aquí podríais pensar que si el listado muestra el “Título” del campo origen, podrías hacer un query a la lista relacionada y devolver el resto de campos que vinculan a ese elemento. Pero… ¿Y si diversas tareas pueden tener el mismo título? Podrías encontrarte que no te retorna los valores que deseas… Un desastre en toda regla. Triste

5.- En SPD 2013 no existe el “else-if”, tan solo “else”:

En SPD 2010:

image

En SPD 2013:

image

En este caso (también incomprensible) está claro que no queda otra que incrustar ramas condicionales independientes (sin “else”) para ir evaluando en cada caso las posibles condiciones. Evidentemente este flujo gastará mayor tiempo de proceso, al tener que analizar cada condición, cuando con el if-else tan sólo hubiera tenido que analizar de forma descendiente hasta encontrar la condición que se cumple en cada caso. En fín, ¡Es lo que hay!

6.- Tan solo se pueden invocar flujos de 2010: SPD 2013 tiene una nueva acción de “Start a List Workflow”, que puede venir estupenda para invocar otros flujos desde el propio flujo, pero ¡Atención!… ¡Sólo se pueden invocar flujos de 2010!

image

7.- Los procesos de aprobación están mucho más limitados en 2013: En SP 2010 podíamos generar una acción de tipo “Start Approval Workflow”, que nos daba la posibilidad de configurar múltiples parámetros de un proceso de validación. Ahora esta acción ya no existe, y en cambio hay otra llamada “Start a Task Process”. Todo cuando permite esta tarea aparece en la siguiente imagen

image

Comparado con la versión 2010 que podíamos modificar el comportamiento de las tareas o del proceso completo, en 2013 nos daremos cuenta enseguida que hemos perdido muchísimas posibilidades de configuración. Un ejemplo flagrante: En 2013 no se puede hacer un “Change Requests” como en 2010 (retornaba la tarea al solicitante para pedirle cambios antes de continuar la validación).

Además, como podréis apreciar en la siguiente imagen, el número de tareas que se pueden realizar en la sección “Task Actions” ha quedado reducida de 6 en 2010 a 2 en 2013. Ahora tan solo podremos asignar una tarea individual a una persona o iniciar un proceso de validación (el que hemos mostrado con más detalle en la imagen anterior).

image

Pues ahí tenéis todas las “incoherencias” que de momento he encontrado en SPD 2013 construyendo flujos de trabajo en modo 2013 (que no son pocas). Supongo que no seré el único en concluir que hay muchas incongruencias en estos flujos. Sobre todo recordad: No os pongáis a implantar flujos en modo 2013 a diestro y siniestro. Si necesitáis acciones como modificar permisos de ítems/documentos, controlar bien un proceso de validación o dejar el flujo pausado hasta que una columna asuma diversos valores posibles, lo tendréis que implantar en modo 2010… o en Visual Studio, claro está.

La duda que dejo en el aire es: ¿Cuando salga SharePoint 2016 (a finales de 2015), los flujos construidos en modo 2010 seguirán siendo compatibles/migrables? Nunca perdáis la esperanza, siempre hay que soñar con un mundo SharePoint mejor…

Entre tanto, ya salió el Cumulative Update 2 para Workflow Manager 1.0, que aporta corrección a bugs, mayor velocidad de proceso (sí, por favor) y acciones para detener y reanudar flujos (habrá que probar si aplican tanto en modo 2010 como 2013): http://support.microsoft.com/kb/2799754

¡¡Saludos!!