Crear un flujo de aprobación con Power Automate — Digitalizar solicitudes y autorizaciones en papel y correo

«Imprimo el documento de aprobación, le pongo el sello, lo paso al departamento de al lado y tarda una semana en volver» o «envío el formulario de Excel adjunto a un correo, y la aprobación llega como un “De acuerdo” en la respuesta». Recibimos con frecuencia consultas de empresas que ya usan Microsoft 365 y quieren resolver este tipo de gestión de solicitudes y aprobaciones.

Power Automate cuenta con un mecanismo específico llamado Aprobaciones (Approvals) que, en muchos casos, permite montar un flujo de aprobación en el que basta con pulsar un botón desde Teams u Outlook, todo dentro del alcance de la licencia, sin coste adicional. Sin embargo, hay una distancia entre lograr que el primer flujo funcione y que pueda operarse con tranquilidad como parte del negocio. ¿Dónde queda el registro de la aprobación? ¿Qué ocurre si el aprobador la deja abandonada? ¿Quién corrige el flujo si la persona responsable deja la empresa? En este artículo se ordenan, desde los componentes básicos del flujo de aprobación, los puntos de diseño donde suele tropezarse en la práctica, hasta el límite de lo que conviene resolver con Power Automate.

1. Conclusión por adelantado

• La aprobación de Power Automate se basa en la acción «Iniciar y esperar una aprobación» (Start and wait for an approval). Se puede elegir entre cinco tipos de aprobación: «se requiere la aprobación de todos», «primera respuesta», «respuesta personalizada (todos/uno)» y «aprobación secuencial».¹
• El aprobador puede responder desde Teams, Outlook, el portal de Power Automate o la aplicación móvil, indistintamente. Casi nunca hace falta que aprenda a usar una pantalla nueva solo para aprobar.²³
• Como punto de entrada de las solicitudes, las opciones realistas son tres: Microsoft Forms, una lista de SharePoint o la aplicación de aprobaciones de Teams. Si más adelante se quiere listar y agregar los datos, lo habitual es apoyarse en una lista de SharePoint.
• El historial de ejecuciones del flujo solo es visible durante 28 días de forma predeterminada, y cada ejecución agota el tiempo de espera a los 30 días como máximo. Desde el principio conviene diseñar el flujo para que el rastro de la aprobación no dependa del historial de ejecuciones, sino que el resultado se escriba de vuelta en una lista de SharePoint u otro destino similar.⁴⁵
• La salida o el traslado del propietario del flujo es el mayor riesgo operativo de un flujo de aprobación. Configure copropietarios y resuelva la gestión de las conexiones el mismo día en que el flujo empiece a funcionar.⁶
• Si se intenta implementar tal cual una aprobación multinivel con muchas ramificaciones condicionales, o un reglamento de aprobación interna con decisión por delegación y requisitos de auditoría estrictos, Power Automate deja de poder mantenerse. En ese caso, entramos en el terreno de un sistema de flujo de trabajo dedicado o de un desarrollo a medida.

2. Qué falla en la aprobación interna en papel y por correo

Lo que hace pesada la aprobación de un documento en papel o de un Excel adjunto a un correo no es tanto el esfuerzo en sí, sino que «no se ve el estado». Al atender consultas, encontramos casi siempre los mismos tres problemas.

• No se sabe en qué punto está detenido. Quien presentó la solicitud no puede ver en el escritorio de quién está el documento ni en qué bandeja de entrada quedó sepultado el correo. Los recordatorios terminan siendo verbales o por teléfono, y a quien los recibe tampoco le resulta agradable.
• Los registros quedan dispersos. El rastro de la aprobación se reparte entre un archivador de papel y buzones de correo individuales. Para averiguar, en una auditoría o en una consulta posterior, «quién aprobó aquella solicitud y cuándo», hay que rebuscar en el buzón de alguien. Si esa persona deja la empresa, el buzón entero desaparece con ella.
• No se puede rastrear la devolución. Cuando el rechazo o la solicitud de corrección se comunican de palabra o por correo, se mezcla a qué versión del formulario correspondía cada observación. Al reenviar la versión corregida, hay que volver a hacer circular todo desde el principio.

Casi todos estos problemas se resuelven «reuniendo el estado y el registro de la solicitud en un solo lugar». Y si la empresa ya usa Microsoft 365, ya dispone del lugar donde guardarlo (SharePoint), de la vía de notificación (Teams/Outlook) y de la automatización (Power Automate).

3. Componentes básicos de la aprobación en Power Automate

La acción «Iniciar y esperar una aprobación»

El núcleo del flujo de aprobación es la acción «Iniciar y esperar una aprobación» (Start and wait for an approval) del conector de Aprobaciones (Approvals). Al indicar el título, los detalles y el aprobador de la solicitud, el flujo se detiene en ese punto, espera la respuesta del aprobador y solo entonces avanza a la siguiente acción.¹

Existen cinco tipos de aprobación.¹

Con la respuesta personalizada se pueden definir opciones como «aprobar», «devolver» y «dejar en espera», en lugar de limitarse a la disyuntiva «aprobar»/«rechazar». Es la pieza que más adelante forma el bucle de devolución.

Cabe señalar que, para usar la función de aprobación, se necesita una base de datos de Microsoft Dataverse. Los registros de las solicitudes y respuestas de aprobación se guardan en Dataverse, que en el entorno predeterminado se aprovisiona automáticamente la primera vez que se crea un flujo de aprobación, por lo que normalmente se empieza a usar sin necesidad de prestarle atención. Como el conector de aprobaciones es un conector estándar, el flujo de aprobación puede crearse con una licencia que permita usar conectores estándar (como Office 365).¹

Qué es Dataverse y en qué momentos hay que prestarle atención

Dataverse, que aparece aquí por primera vez, es la plataforma común de almacenamiento de datos de Power Platform. En términos sencillos, es una base de datos en la nube que se aprovisiona dentro del propio inquilino (tenant) de Microsoft 365 de la empresa, y sirve como lugar donde se guardan los datos que manejan las aplicaciones de Power Apps y los flujos. La función de aprobación se apoya en ella: «a quién y cuándo se pidió la aprobación, y quién respondió y cómo» se escribe como registros en las tablas de Dataverse.

En la creación y el funcionamiento del día a día casi nunca hace falta prestar atención a Dataverse, pero asoma en estas tres situaciones.

• Al usar la aprobación por primera vez en un entorno nuevo. En el entorno predeterminado se aprovisiona automáticamente, pero en un entorno creado a propósito para un departamento hay que comprobar si existe una base de datos de Dataverse.¹
• Cuando se acumula el historial de aprobaciones. Ese historial consume el almacenamiento del entorno y puede llegar a ser objeto de eliminación por motivos de capacidad. Aquí está la razón por la que el rastro de la aprobación no debe depender ni del historial de ejecuciones ni de Dataverse (véase el siguiente capítulo).⁷
• Cuando se quiere leer o escribir directamente los registros de aprobación. Si se configura el acceso directo a las tablas mediante el conector de Dataverse, ese conector se clasifica en el nivel Premium, con lo que entra en juego el tema de una licencia adicional.⁸

En resumen, la línea divisoria es esta: «usar la aprobación de forma normal no exige ninguna licencia adicional, pero en cuanto se empieza a tocar Dataverse directamente, el panorama cambia».

Desde dónde responde el aprobador

La solicitud de aprobación llega al aprobador por correo electrónico y por la aplicación móvil de Power Automate.³ En Outlook llega un correo de aprobación con formato específico, desde el que se puede responder.⁹ Las aprobaciones dirigidas a un usuario individual también se notifican en Teams, donde se puede aprobar, rechazar y añadir comentarios desde el chat o desde la aplicación de aprobaciones.² Que no exista la barrera de «tener que iniciar sesión en un sitio dedicado para aprobar» es el mayor impulsor de que el flujo de aprobación se afiance en el uso diario.

Hay un punto de atención: si el destinatario de la aprobación es un grupo de Microsoft 365, no se envía notificación de Teams. Esa notificación solo llega en las aprobaciones dirigidas a un usuario individual.¹⁰

Panorama general del flujo

Tomando como ejemplo una solicitud de compra, el conjunto queda así.

flowchart TD
    Submit[La persona solicitante ingresa los datos<br/>Envío de Forms / Registro en lista de SharePoint] --> Trigger[Se inicia el flujo en la nube<br/>Desencadenador: nueva respuesta / elemento agregado]
    Trigger --> Record[Se registra el contenido de la solicitud en la lista de SharePoint<br/>Estado: pendiente de aprobación]
    Record --> Approval[Iniciar y esperar una aprobación<br/>Se envía la solicitud al aprobador]
    Approval -- Teams / Outlook / móvil --> Response{Respuesta}
    Response -- Aprobación --> UpdateOK[Se actualiza el estado de la lista a «Aprobado»<br/>Se registran en columnas el aprobador, la fecha/hora y los comentarios]
    Response -- Rechazo/devolución --> UpdateNG[Se actualiza el estado a «Devuelto»<br/>Se notifica el motivo a la persona solicitante]
    Response -- Tiempo de espera agotado --> Remind[Aviso de recordatorio / escalación]
    UpdateOK --> NotifyOK[Se notifica el resultado a la persona solicitante]
    UpdateNG --> Resubmit[La persona solicitante corrige y vuelve a presentar la solicitud]
    Resubmit -- Se inicia solo con<br/>«nueva presentación» por condición del desencadenador --> Trigger

El punto clave es intercalar un paso de «registro» antes y después de la acción de aprobación. La razón se explica en el capítulo 5.

4. Cómo diseñar el punto de entrada de las solicitudes

La comodidad de uso de un flujo de aprobación depende más del punto de entrada donde se capturan las solicitudes que del lado de la aprobación. Hay tres opciones realistas.

La pauta para decidir es la siguiente.

• Si lo único que se quiere es digitalizar aprobaciones puntuales, basta con la aplicación de aprobaciones de Teams, sin necesidad de crear un flujo. Esta app permite enviar una solicitud de aprobación al instante desde el chat; funciona sobre la base de Power Automate, pero no requiere crear un flujo.¹¹
• Para sustituir un formulario de solicitud, el camino más corto es usar Forms como entrada, recibir la respuesta en un flujo y encaminarla a la aprobación. También existen plantillas que insertan el contenido de la respuesta de Forms en la solicitud de aprobación.¹³
• Para gestionarlo como un registro de solicitudes, hay que apoyarse en una lista de SharePoint. Incluso si Forms es la puerta de entrada, con solo trasladar la respuesta a la lista al comienzo del flujo, una columna de estado (pendiente de aprobación/aprobado/devuelto) y las vistas dejan a la vista de cualquiera «dónde está detenido en este momento». La respuesta al problema de la aprobación en papel y correo planteado al inicio está, en la práctica, aquí.

Si se empieza a pequeña escala, la configuración de «recibir con Forms, registrar en una lista de SharePoint y escribir también en la lista el resultado de la aprobación» resulta manejable, porque combina la facilidad de entrada con la gestión de un registro.

5. Puntos de diseño que funcionan en la práctica

Dónde dejar constancia de la aprobación: no depender del historial de ejecuciones

Es la decisión de diseño más importante. El historial de ejecuciones del flujo solo se muestra, de forma predeterminada, durante 28 días.⁴ Si el flujo forma parte de una solución, los metadatos del historial de ejecuciones pueden conservarse en Dataverse, pero ahí también la retención predeterminada es de 28 días, y es el administrador quien puede ajustar ese periodo.¹⁴

Es decir, apoyarse en el historial de ejecuciones para averiguar más tarde «quién aprobó y cuándo» se viene abajo en apenas un mes. Los registros de la solicitud y la respuesta de aprobación en sí se guardan en Dataverse¹⁵, pero no es realista abrir la tabla de Dataverse cada vez que hay que atender una auditoría o una consulta cotidiana, y además el historial de aprobaciones consume el almacenamiento del entorno, por lo que también puede llegar a eliminarse por motivos de capacidad.⁷

En la práctica, conviene incluir siempre, justo después de la acción de aprobación, un paso que escriba el resultado, el aprobador, la fecha/hora de la respuesta y los comentarios en columnas de una lista de SharePoint. Como la acción «Iniciar y esperar una aprobación» devuelve la respuesta, el aprobador y los comentarios como salida¹⁵, basta con registrarlos tal cual en las columnas. Así la solicitud y el registro de aprobación quedan alineados en la misma fila de la misma lista, y el periodo de conservación puede extenderse durante años, según cómo se gestione la lista.

Hay un único punto de atención: en los tipos con varios aprobadores, como «se requiere la aprobación de todos» o la respuesta personalizada (todos), las respuestas (Responses) se devuelven como una matriz con una entrada por persona.³ Si esto se escribe secuencialmente, sobrescribiendo un único conjunto de columnas, solo queda la última respuesta; por eso, el registro de varios aprobadores debe hacerse añadiendo una fila por respuesta en una lista de historial, o dando formato a las respuestas de todos en un solo bloque de texto antes de registrarlas en la columna.

Tiempo de espera agotado y recordatorios: no se puede crear una «aprobación sin plazo»

Cada ejecución de un flujo en la nube dura, como máximo, 30 días. Ese plazo de 30 días incluye los pasos pendientes, como la espera de una aprobación, y al superarlo esos pasos pendientes agotan el tiempo de espera.⁵ Si el aprobador deja la solicitud abandonada, el flujo termina en un fallo silencioso. Si se empieza a operar sin saber esto, ocurre el incidente que más deteriora la confianza: «presenté la solicitud y no pasa nada».

La medida se aplica en dos niveles.

1. Configurar un tiempo de espera explícito en la acción de aprobación. En la configuración de la acción se indica el tiempo de espera en formato ISO 8601 (por ejemplo, P3D para 3 días), y en Configurar la ejecución después de se prepara la ramificación para el caso de «Se ha agotado el tiempo de espera».¹⁶ Aquí conviene tener presente que, en el momento en que se agota el tiempo de espera, la espera de aprobación original ya ha terminado. Aunque el aprobador responda después, esa respuesta no llega a los pasos posteriores de esta ejecución (como la escritura del resultado). Es decir, la rama de tiempo de espera agotado no es el lugar para «seguir esperando mientras se envía un recordatorio», sino para «dar por terminada la espera y tomar la siguiente medida». Si se quiere enviar un recordatorio, hay que hacerlo enviando un aviso en esa rama y, además, volviendo a emitir una nueva solicitud de aprobación.
2. Cuando la aprobación puede superar los 30 días, dividir el flujo en dos. La documentación oficial recomienda una configuración en la que la acción «Crear una aprobación (v2)» solo envía la solicitud, con lo que termina el primer flujo, y el procesamiento posterior de la respuesta se realiza en otro flujo distinto. Como el registro de aprobación está en Dataverse, la respuesta puede procesarse aunque la ejecución del flujo original ya haya terminado. Esta configuración de dos flujos también es la más sencilla de construir cuando se quiere montar un recordatorio flexible sin cortar la espera.¹⁷ Cabe señalar que la forma de iniciar el segundo flujo admite varios diseños; si se opta por capturar directamente los cambios en la tabla de aprobación mediante el desencadenador del conector de Dataverse, tenga en cuenta que ese conector entra en el ámbito de la licencia Premium (las acciones del propio conector de aprobaciones siguen dentro del alcance estándar¹).⁸

Procedimiento para configurar el tiempo de espera y la ramificación

Como en texto resulta difícil de seguir, se detallan a continuación los pasos en el diseñador.

1. Desde el «…» de la esquina superior derecha de la tarjeta de la acción «Iniciar y esperar una aprobación», abra Configuración (Settings) e introduzca en el campo Tiempo de espera (Timeout) una duración en formato ISO 8601. Para 3 días es P3D; para 12 horas, PT12H. Si se deja en blanco, esperará hasta el límite de duración de la ejecución del flujo (30 días).
2. Debajo de la acción de aprobación, coloque una acción con el procesamiento que se quiera realizar cuando se agote el tiempo de espera (por ejemplo, un aviso de recordatorio).
3. Desde el «…» de la esquina superior derecha de la tarjeta de esa acción, abra Configurar la ejecución después de (Configure run after) y marque únicamente «Se ha agotado el tiempo de espera» para la acción de aprobación anterior. La opción predeterminada es «Se ha realizado correctamente», así que no olvide desmarcarla.
4. El procesamiento para el caso de aprobación (escribir el resultado, notificar a la persona solicitante) se coloca como la otra rama que sale de la acción de aprobación, y en ese caso se deja «Se ha realizado correctamente» tal cual. Al ramificar mediante la configuración de la ejecución después de, el diseñador muestra las dos ramas en paralelo.

Cómo construir «recordatorio a los 3 días, escalación a un superior a los 7»

Suponemos que esto es justo lo que más se querrá construir, así que se muestra en concreto una configuración en serie de dos o tres niveles: en el primer nivel se espera 3 días; si no hay respuesta, se envía un recordatorio y se vuelve a emitir la solicitud al mismo superior directo; y si pasan otros 4 días, se traslada a un superior de mayor rango.

flowchart TD
    A1[Iniciar y esperar una aprobación, nivel 1<br/>Aprobador: superior directo<br/>Tiempo de espera configurado: P3D] --> Q1{Hubo respuesta}
    Q1 -- Aprobación/rechazo --> Rec[Se escribe el resultado en la lista de SharePoint<br/>Se notifica a la persona solicitante]
    Q1 -- 3 días sin respuesta --> R1[Se envía un aviso de recordatorio<br/>Configurar la ejecución después de: se ha agotado el tiempo de espera]
    R1 --> A2[Iniciar y esperar una aprobación, nivel 2<br/>Aprobador: el mismo superior directo<br/>Tiempo de espera configurado: P4D]
    A2 --> Q2{Hubo respuesta}
    Q2 -- Aprobación/rechazo --> Rec
    Q2 -- 4 días más sin respuesta --> R2[Se envía un aviso de escalación<br/>Configurar la ejecución después de: se ha agotado el tiempo de espera]
    R2 --> A3[Iniciar y esperar una aprobación, nivel 3<br/>Aprobador: superior de mayor rango<br/>Sin tiempo de espera configurado]
    A3 --> Rec

Hay tres puntos clave a la hora de construirlo.

• Los niveles 2 y 3 son «nuevas solicitudes de aprobación». Como la solicitud del nivel 1 ya terminó a los 3 días, llega al Teams o al Outlook del aprobador como una solicitud distinta. Si se añade «[Recordatorio]» o «[Escalación]» al título de la solicitud, y se incluye en el cuerpo la fecha de presentación y los días transcurridos, quien la recibe puede entender la situación.
• La suma de los tiempos de espera debe caber dentro de los 30 días del flujo. En el ejemplo anterior, los 3 días del nivel 1 más los 4 días del nivel 2 consumen 7 días, así que al nivel 3 le quedan poco menos de 23 días. Cuantos más niveles se añaden, menos margen queda para el último.
• Si se quiere reunir la escritura del resultado en un solo lugar, use variables. Como el resultado de la aprobación es la salida de una acción distinta en cada nivel, si se escribe tal cual, los pasos de escritura se multiplican por tres. Es más fácil de mantener si al principio del flujo se inicializan variables de texto (por ejemplo, ResultadoAprobacion) y Aprobador, se coloca una acción «Establecer variable» justo después de la acción de aprobación de cada nivel, y al final se escribe todo de una sola vez en la lista.

También es posible construir «tiempo de espera → recordatorio → nueva solicitud» con un bucle Do until, pero este tiene su propio límite de bucle (60 iteraciones y 1 hora, de forma predeterminada), independiente de todo lo anterior. Si dentro de él se coloca una acción de larga duración como la espera de una aprobación, hay que ampliar explícitamente el tiempo de espera del bucle mediante «Cambiar límites»; de lo contrario, tras la primera vuelta no arrancará la segunda.⁵¹⁸ Ese «Cambiar límites (Change limits)» es un enlace dentro de la tarjeta de la acción Do until y, al abrirlo, permite indicar dos valores: Recuento (Count) y Tiempo de espera (Timeout). El recuento es el número de iteraciones (60 de forma predeterminada), y el tiempo de espera es el campo donde se escribe en ISO 8601 el límite de tiempo de todo el bucle (PT1H de forma predeterminada). Si se quiere dar tres vueltas a una aprobación que espera 3 días cada una, hay que poner el recuento en 3 y el tiempo de espera en un valor «superior a la suma del tiempo de vuelta previsto», como P10D. Sin embargo, aunque se amplíe este valor, no se extienden los 30 días del flujo en su conjunto.

En la aprobación interna de una pyme, lo realista es empezar decidiendo una regla interna del tipo «recordatorio a los 3 días, escalación al superior a los 7», e implementarla mediante un bucle de nueva solicitud o mediante la configuración de dos flujos.

Reasignación en caso de ausencia

Tarde o temprano se dará el caso de un aprobador ausente durante mucho tiempo. La persona que recibió la solicitud de aprobación puede reasignarla (Reassign) a otra persona desde la lista de aprobaciones del portal de Power Automate. Por el lado de quien envió la solicitud, en cambio, el modo de resolverlo consiste en cancelar la solicitud, cambiar el aprobador y volver a ejecutar el flujo.⁹ Conviene tener presente que, en un flujo de inicio automático como el de este artículo, esta es una tarea que corresponde al propietario del flujo, no a la persona solicitante, porque la solicitud de aprobación se envía desde la cuenta usada en la conexión del flujo, y cambiar el aprobador requiere permiso de edición sobre el flujo. Hay que decidir de antemano, junto con el tema de los copropietarios que se trata en el siguiente capítulo, «quién corrige el flujo cuando el aprobador está de baja».

Ahora bien, la reasignación parte de la premisa de que «quien la recibió puede operarla», por lo que no sirve ante una baja repentina. Como medida permanente, es más seguro no fijar un único aprobador individual, sino indicar varias personas separadas por punto y coma con el tipo «primera respuesta», o bien diseñar el envío a un grupo.⁹ Como el envío a un grupo tiene la restricción de que no se envía la notificación de Teams¹⁰, si lo que se prioriza es la fiabilidad de la notificación, conviene optar por indicar varias personas.

El bucle de devolución en caso de rechazo

El ciclo «devolución → corrección → nueva presentación», el más difícil de rastrear en la aprobación en papel, se puede representar de forma directa con un diseño que use una columna de estado. La forma básica es la siguiente.

• Definir «Aprobar» y «Devolver» mediante una respuesta personalizada¹
• En caso de devolución, cambiar la columna de estado de la lista a «Devuelto», registrar el comentario del aprobador en una columna y notificar a la persona solicitante
• La persona solicitante corrige el elemento de la lista y cambia el estado a «Nueva presentación» (o vuelve a enviarlo desde Forms)
• El flujo vuelve a ejecutarse con el desencadenador de actualización del elemento, y la solicitud pasa de nuevo a aprobación

Con este diseño hay un punto que exige atención: la propia escritura del flujo puede volver a reiniciarlo. Si se deja el desencadenador «Cuando se crea o modifica un elemento» tal cual, en el momento en que el flujo actualiza la columna de estado a «Pendiente de aprobación» o «Aprobado», esa misma actualización cumple la condición del desencadenador, y se producen solicitudes de aprobación duplicadas o un bucle infinito. Un flujo en la nube puede desencadenarse a sí mismo, y Power Automate también advierte de esa posibilidad de bucle infinito al guardar.¹⁹ La solución no es descartarlo mediante una ramificación condicional posterior, sino escribir en el propio desencadenador, mediante condiciones del desencadenador (trigger conditions), que «solo se inicie cuando la columna de estado sea ‘Nueva presentación’ (o al crearse)». Con una actualización que no cumple la condición del desencadenador, ni siquiera se produce la ejecución del flujo, por lo que tampoco se consume el contador de ejecuciones.²⁰

Las condiciones del desencadenador se configuran abriendo Configuración (Settings) desde el «…» de la esquina superior derecha de la tarjeta del desencadenador, y escribiendo en Condiciones del desencadenador (Trigger Conditions) una expresión por línea, comenzando por @. Si se quiere que se inicie solo cuando la columna de opciones ApprovalStatus de la lista de SharePoint sea «Nueva presentación», queda así.

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], 'Nueva presentación')

Si también se quiere que se inicie al crearse (columna de estado vacía), se combina con or.

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], 'Nueva presentación'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

Hay tres puntos que conviene tener presentes sobre esta forma de escribirlo.

• El @ va solo una vez, al principio. No se antepone a los equals o empty anidados en el interior.
• En una columna de opciones hay que llegar hasta /Value. Como una columna de opciones se devuelve como un objeto y no como una cadena de texto, comparar con body/ApprovalStatus no produce coincidencia. En una columna de texto de una línea, /Value no hace falta.
• No use nombres en japonés (u otro idioma no latino) para el nombre interno de la columna. Si el nombre de una columna de SharePoint se escribe en japonés, el nombre interno se convierte en una cadena codificada como _x72b6__x614b_, y escribir el nombre para mostrar tal cual en la expresión no produce coincidencia. Si la columna que se referencia desde el flujo se crea primero con un nombre alfanumérico y después se cambia el nombre para mostrar al idioma local, se evita este tipo de desgaste con las expresiones. El nombre interno puede consultarse en la URL de la página de detalles de la columna, en la configuración de la lista (después de Field=).

El historial de correcciones queda en el historial de versiones de la lista, lo que también resuelve el problema de que se mezcle «a qué versión correspondía cada observación». También es posible construir un bucle Do until dentro del flujo para hacer circular la devolución dentro de una sola ejecución, pero como el límite de 30 días de la ejecución incluiría también el tiempo de ida y vuelta de la devolución, es más seguro diseñarlo de modo que cada devolución termine la ejecución, y la nueva presentación inicie una ejecución nueva.

6. Operación y gobernanza: que el flujo no sea «propiedad de quien lo creó»

Como un flujo de aprobación se integra en el núcleo del negocio, si queda ligado a una sola persona, el impacto de su ausencia es grande. Como mínimo, conviene resolver estos dos puntos el mismo día en que empieza a funcionar.

• Configure copropietarios. El propietario de un flujo puede consultar el historial de ejecuciones, editar o detener el flujo e incluso actualizar las credenciales de la conexión. Si se deja con un único creador, en el momento en que esa persona deje la empresa o cambie de puesto, nadie podrá corregir el flujo. Añada como copropietarios al personal de sistemas de información o a los posibles sucesores. Existe también la función de convertir la propia lista de SharePoint en copropietaria, de modo que «quien tiene permiso de edición sobre la lista = quien puede editar el flujo»⁶, pero si se hace esto en una lista de entrada donde escriben todas las personas solicitantes, como en este artículo, se acabaría dando permiso de edición del flujo a todas ellas. No la use en un flujo de aprobación: limite los copropietarios a las personas concretas responsables de la operación o a un grupo administrativo.
• Comprenda cómo se gestionan las conexiones. Las conexiones que usa el flujo (la autenticación hacia SharePoint u Outlook) están vinculadas al usuario que las creó, y una conexión compartida solo puede usarse dentro de ese flujo. Además, un copropietario no puede cambiar las credenciales de una conexión creada por otro propietario.⁶ De aquí surgen incidentes como que el correo de notificación del resultado de la aprobación siga enviándose desde «la cuenta de alguien que ya dejó la empresa», o que el flujo se detenga en el momento en que se deshabilita esa cuenta. Qué cuenta usar para las notificaciones y las escrituras es un punto que debe decidirse antes de crear el flujo.

Cabe señalar que, incluso cuando se hace que otros departamentos usen el flujo, no es necesario compartirlo con las personas que presentan solicitudes. En la configuración de este artículo, basta con que puedan introducir datos en el punto de entrada (Forms o la lista de SharePoint) para que el flujo se inicie automáticamente. El principio es limitar el objeto de la compartición a quienes se ocupan de la edición y la operación, y mantener los copropietarios al mínimo necesario.²¹

La gobernanza general de Power Automate —licencias, separación de entornos, políticas DLP— se trata en otro artículo, «Automatizar procesos con Power Automate: cómo elegir entre flujos en la nube y flujos de escritorio, y el diseño del tratamiento de errores». Como el flujo de aprobación también es un tipo de flujo en la nube, el mismo planteamiento se aplica tal cual.

7. Hasta dónde llegar con Power Automate

La aprobación de Power Automate es potente, pero no es una herramienta pensada para implementar tal cual un reglamento de aprobación interna. A continuación, algunas pautas para trazar el límite.

Como criterio intuitivo, consideramos que, en cuanto las ramificaciones del flujo dibujadas en papel dejan de caber en una hoja A4, se está empezando a superar el ámbito de Power Automate. En lugar de forzar el crecimiento del flujo, suele salir más barato, a fin de cuentas, sacar solo la lógica de decisión de la ruta de aprobación a un sistema externo (una tabla de Dataverse u otro sistema), o directamente decidir migrar a un sistema dedicado.

Además, digitalizar el flujo de aprobación suele ser también la puerta de entrada para revisar los intercambios en papel y por fax con el exterior. Una vez digitalizada la aprobación interna, los siguientes candidatos son la recepción de pedidos por fax o el intercambio de facturas. Este tema se trata en «Cómo trasladar la recepción de pedidos por fax a la Web: el diseño del periodo de operación doble y la práctica de la migración por etapas» y en «¿Qué es el EDI? Cómo facilita los pedidos entre empresas: de fax, correo y entrada manual a la integración de datos».

8. Resumen

El verdadero problema de la aprobación interna en papel y correo no era el esfuerzo, sino que «no se veía el estado, los registros quedaban dispersos y no se podía rastrear la devolución». El flujo de aprobación de Power Automate resuelve estos tres puntos reuniendo la solicitud y el registro de aprobación en una lista de SharePoint, y dejando la operación de aprobar en manos de Teams/Outlook. Que en muchos casos pueda empezarse a usar sin inversión adicional en sistemas es también una gran ventaja para las empresas que ya cuentan con Microsoft 365.

Por otro lado, si se construye sin conocer las restricciones de 28 días de historial de ejecuciones y 30 días de duración de la ejecución, se acaba con un flujo de aprobación en el que «el rastro desaparece» y «las solicitudes fallan en silencio». La escritura del resultado, la ramificación de tiempo de espera agotado, los múltiples aprobadores y los copropietarios: si estos cuatro puntos se incorporan al diseño desde el principio, el flujo de aprobación puede operar durante mucho tiempo con tranquilidad. Y el momento en que surge la tentación de implementar tal cual toda la complejidad de un reglamento de aprobación interna es precisamente cuando conviene plantearse un sistema dedicado o un desarrollo a medida.

Artículos relacionados

• Automatizar procesos con Power Automate: cómo elegir entre flujos en la nube y flujos de escritorio, y el diseño del tratamiento de errores
• Cómo trasladar la recepción de pedidos por fax a la Web: el diseño del periodo de operación doble y la práctica de la migración por etapas
• ¿Qué es el EDI? Cómo facilita los pedidos entre empresas: de fax, correo y entrada manual a la integración de datos
• ¿Qué es la factura digital? En qué se diferencia de «enviar el PDF de la factura por correo»

Áreas de consultoría relacionadas

KomuraSoft LLC atiende desde consultas sobre la digitalización de flujos de trabajo aprovechando Microsoft 365, hasta la sistematización de requisitos de aprobación e impresos que superan lo que Power Automate puede cubrir.

• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se puede crear un flujo de aprobación de Power Automate únicamente con una licencia de Microsoft 365?

Sí. El conector de aprobaciones (Approvals) es un conector estándar, por lo que basta con una licencia que permita usar conectores estándar (como Office 365) para crear el flujo de aprobación. No obstante, se necesita una base de datos de Microsoft Dataverse como destino de almacenamiento de los datos de aprobación; en el entorno predeterminado, esta se aprovisiona automáticamente la primera vez que se crea un flujo de aprobación. La combinación con listas de SharePoint, Forms, Teams y Outlook también puede configurarse dentro del alcance de los conectores estándar.

¿Qué ocurre si el aprobador deja la solicitud sin responder?

Cada ejecución de un flujo en la nube dura como máximo 30 días, y los pasos pendientes, como la espera de una aprobación, también entran en tiempo de espera agotado (timeout) al superar ese plazo. Por eso no es posible crear una «aprobación sin plazo». En la práctica, se configura un tiempo de espera explícito en la acción de aprobación y, en «Configurar la ejecución después de», se prepara la ramificación para el caso de «Se ha agotado el tiempo de espera». Cuando se agota el tiempo de espera, la solicitud de aprobación original finaliza y, aunque el aprobador responda después, esa respuesta ya no llega a los pasos posteriores de esta ejecución. Por eso esta rama no sirve para «seguir esperando mientras se envía un recordatorio», sino para «dar por terminada la espera y tomar la siguiente medida»: se diseña para enviar un aviso de recordatorio y, junto con él, volver a emitir una nueva solicitud de aprobación (escalándola a un superior según el número de repeticiones). Si es necesario esperar más de 30 días, se separa el proceso en dos flujos: uno con la acción «Crear una aprobación (v2)» y otro que procesa la respuesta.

¿Dónde queda el registro de las aprobaciones? ¿Se puede usar para auditorías?

Las solicitudes y respuestas de aprobación se guardan como registros en Microsoft Dataverse, pero el historial de ejecuciones del propio flujo solo se muestra durante 28 días de forma predeterminada. Confiar en el historial de ejecuciones para auditorías o consultas posteriores es arriesgado. En la práctica, se recomienda diseñar el flujo para que, al final, escriba el resultado de la aprobación, el aprobador, la fecha y hora, y los comentarios en columnas de una lista de SharePoint, de modo que los datos de la solicitud y el registro de aprobación puedan consultarse juntos en un solo lugar.

¿Qué se debe hacer cuando el aprobador está ausente o ha dejado la empresa?

La persona que recibió la solicitud de aprobación puede reasignarla (Reassign) a otra persona desde la lista de aprobaciones de Power Automate. Quien envió la solicitud no puede reasignarla directamente, pero puede cancelarla, cambiar el aprobador del flujo y volver a ejecutarlo. Para prevenir ausencias prolongadas, conviene no fijar un único aprobador individual, sino diseñar el envío a varias personas o a un grupo, lo que reduce el riesgo de bloqueo. También es importante configurar copropietarios desde el principio, para prever la salida del propietario del propio flujo.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.