Nuestro día a día se compone de multitud de tareas en las que, en ocasiones, debemos interactuar con diferentes departamentos. A menudo estos procesos pueden requerir de varios niveles de aprobación o interacción, lo que en muchas organizaciones se traduce en conversaciones telefónicas, escritura de emails, mensajes por Microsot Teams… en definitiva, tiempo, interrupciones de nuestro trabajo y la posibilidad de que en algún punto se rompa la cadena y el proceso se interrumpa, incurriendo por tanto en ineficiencias.
En este post vamos a explicar la lógica detrás de un flujo de aprobación de PowerApps mediante el cual un empleado (nuestro compañero imaginario Alex Wilber) realizará una petición de autorización de viaje a través de un formulario de Microsoft 365 Forms, como este llegará a su manager (Adele Vance ) automáticamente para que apruebe o deniegue la petición , y en caso de que la apruebe, se envíe al departamento de compras para su tramitación administrativa.
Para hacerlo necesitaremos:
- Definir la jerarquía en Azure AD
- Un formulario de Microsoft Forms
- Un flujo de aprobación de Power Automate
Por cierto, todo lo que necesitamos está incluido sin coste adicional con cualquier licencia de Office 365.
¡Empecemos!
Definición de la jerarquía en Office 365 – Azure AD
La jerarquía de Office 365, es parte de los metadatos de usuario de la plataforma. Esto nos permite en esta ocasión automatizar el envío de formularios al aprobador adecuado (el mánager del usuario), pero en realidad podemos automatizar cualquier acción: peticiones de ausencias, aprobación de un documento o proceso, realizar determinada acción si un usuario no inicia sesión antes de una hora definida, etc.
Para este ejemplo es preciso comprobar si el usuario Alex tiene informado este parámetro.
Para hacerlo, nos dirigimos al portal de Azure y accedemos al portal de administración de Azure AD
Vamos a la pestaña usuarios y seleccionamos el usuario que queramos comprobar.
Una vez en el perfil de Alex verificamos que efectivamente Adele es la responsable de Alex, y por lo tanto podríamos seguir con el proceso. La traducción que hace la plataforma de responsable es “administrador”, lo que sería una traducción literal de “manager”. Quizá no lo más acertado, pero en cualquier caso quedaros con ello porque se sigue haciendo referencia a ello durante el proceso.
En caso de que no estuviese informado, un administrador del sistema puede rellenar esta información a través del botón Editar; si bien lo deseable es que se completen los metadatos a la incorporación de cada usuario, o durante la migración en caso de que hubiésemos llegado a Office 365 desde otra plataforma.
Diseño y envío del formulario
El Proceso de diseño del formulario es tan sencillo como crear un documento en Word o correo electrónico. Nos dirigimos al portal de Office 365 , y seleccionamos la aplicación Forms (si no nos aparece presionamos «Más aplicaciones»).
Una vez dentro de la aplicación, presionamos Nuevo formulario y creamos el formulario según nuestras preferencias y necesidades.
Cuando finalicemos con el diseño, lo publicaremos obteniendo en enlace, pulsando sobre el botón “Compartir” que visualizaremos en la parte superior derecha de la pantalla.
Este enlace, podemos publicarlo en la intranet, compartirlo por correo electrónico o en general cualquier método para que nuestros usuarios puedan acceder completar las respuestas.
Creación del flujo de automatización
Llegamos a la parte más interesante que es la automatización del proceso. Para hacerlo haremos uso de Power Automate (antiguamente Flow).
A través del portal de Office 365, nos dirigiremos en esta ocasión a la app Power Automate, y presionaremos en «Crear».
En la siguiente pantalla, podemos elegir el tipo de flujo que nos interese, entre un flujo totalmente en blanco para hacer un diseño a medida, flujo de ejecución a petición, programado diariamente, entre otros.
Mi recomendación es empezar por alguna de las plantillas para empezar a entender el funcionamiento del sistema, y adaptarla para nuestras necesidades.
Veamos a continuación las diferentes partes del flujo ya completado, comentando los aspectos más interesantes.
En el primer paso, el desencadenador, es decir el elemento que provoca que se arranque el proceso. En este caso seleccionamos como desencadenador “Cuando se crea una respuesta a un formulario”, seleccionando el formulario en cuestión desde el desplegable. Si nuestro formulario no aparece en el desplegable, podemos pegar su enlace.
A continuación, obtenemos las respuestas desde el formulario para su proceso dentro de la lógica de trabajo. Acto seguido, obtenemos el nombre del “administrador” o el mánager / responsable de la persona que ha mandado el formulario (responder’s email) y empezamos con la lógica de proceso. Los metadatos que podemos incluir en cada paso vienen definidos por los métodos que hemos usado durante el flujo.
Podemos personalizar totalmente la lógica y el condicionado desde el tipo de aprobación (aprueba el primero que lo recibe, aprueban varios, aprobación en cadena), a quien se asigna la petición, título de la petición de aprobación que recibirá el mánager, y los detalles de la respuesta que acabamos en enviar, que podemos cumplimentar con los campos dinámicos disponibles.
Finalmente, nos centramos en la lógica de resolución:
Vemos que en caso de que se apruebe se envía un correo electrónico a compras, con el peticionario en copia (esto se especifica en las opciones avanzadas), con todos los detalles de la petición para su tramitación. En caso negativo notificamos al usuario para que revise los comentarios de la denegación para corregirlo. Utilizamos el contenido dinámico, para adaptar los correos con los metadatos del formulario que queramos.
En este caso hemos terminado el flujo en un correo, pero bien podría terminarse en que se realizara una entrada en una lista de SharePoint, que, a su vez, estuviese conectada un flujo que automatizara una notificación a un tercero, o cualquier otra acción. Las posibilidades son infinitas.
Look & Feel
Vamos a ver finalmente que verían los implicados en el proceso:
- La persona que rellena el formulario, al que accedería a través del enlace, publicado en su intranet:
- El aprobador puede recibir la petición a través de un mensaje de correo electrónico, en un canal de Microsoft Teams, o en la propia aplicación de Flow. Desde todos ellos podrá interactuar directamente para aprobarla o denegarla.
- El peticionario y el departamento de compras una vez aprobada o denegada la solicitud por el mánager. Aquí podríamos trabajar el aspecto gráfico, o el contenido que queramos que el destinatario final visualice o incluso el enlace a la respuesta del formulario.
Resumen
Tal y como hemos visto, Microsoft 365 no es solo un ecosistema de ofimática y gestión documental en la nube, sino toda una plataforma de productividad que, combinado con Power Automate, nos brinda capacidades de automatización de procesos e integración de aplicaciones desde cualquier origen, hacia cualquier destino.
