Una solicitud que pasa por varias bandejas de correo puede perder su responsable, su versión o su respuesta final. Para una empresa en Chile que ya utiliza Microsoft 365, Power Automate permite ordenar ese recorrido: registrar la petición, pedir una decisión humana y conservar el resultado. El primer paso es elegir un proceso pequeño y definir cómo comprobar que funciona.
Esta guía propone un piloto de aprobación de material comercial interno. El ejemplo es ficticio: no representa un cliente ni resultados obtenidos por NOVVOR. Antes de implementarlo, valida los permisos y las reglas de tu organización en un entorno de pruebas.
1. Define qué se aprueba y cuándo termina la solicitud
Imagina que un equipo solicita revisar la ficha de un servicio antes de usarla en una presentación. Para el piloto, cada solicitud corresponde a una versión concreta del documento. Si cambia el contenido después de enviarlo, la aprobación anterior no debe trasladarse automáticamente a la nueva versión.
Acuerda estos elementos con el responsable del proceso:
- Qué material entra al circuito y qué queda fuera.
- Quién puede solicitar la revisión y quién puede decidir.
- Qué información necesita el aprobador: identificador, versión, descripción del cambio y enlace al material.
- Qué plazo de respuesta tiene sentido y quién atiende una excepción.
- Qué significa terminar: aprobado, rechazado, vencido o con un error pendiente de resolver.
Separa la decisión de su ejecución. Un documento puede estar aprobado y, aun así, fallar la actualización del registro. Mostrarlo como completamente terminado ocultaría una tarea pendiente. Para empezar, evita automatizar la publicación externa del material: el piloto puede terminar con el registro de la decisión y una notificación interna.
2. Revisa licencias y acceso antes de construir
El conector de aprobaciones es estándar. Microsoft indica que crear estos flujos requiere una licencia válida con acceso a Power Automate y a conectores estándar; las aprobaciones utilizan Dataverse. El aprovisionamiento inicial depende del entorno y puede requerir intervención administrativa. Esto no convierte cualquier integración del flujo en una función incluida: revisa también los conectores adicionales y los derechos de quienes lo usarán. Consulta los requisitos oficiales de aprobaciones.
Comprueba que el aprobador puede abrir el documento enlazado y que un solicitante solo ve los registros que corresponden a su rol. Una notificación recibida no demuestra acceso correcto al archivo. No añadas datos de clientes ni información personal para hacer más realista la prueba; bastan documentos y solicitudes ficticias.
3. Elige la regla de aprobación humana
La regla debe representar la decisión del negocio. Para el ejemplo, si basta la decisión de uno de dos revisores disponibles, puedes usar Approve/Reject – First to respond: la primera aprobación o rechazo resuelve la solicitud. Si dos responsables deben autorizar el material, Approve/Reject – Everyone must approve espera ambas aprobaciones; un rechazo basta para rechazarla. Microsoft documenta esta diferencia en su guía para múltiples aprobadores.
No uses “primero en responder” cuando la política exige dos revisiones. Si una segunda persona debe revisar después de la primera, diseña etapas secuenciales y define qué hacer si la etapa anterior rechaza. Este piloto usa destinatarios individuales: las aprobaciones dirigidas a grupos tienen un comportamiento propio y deben evaluarse aparte.
4. Construye un recorrido que puedas inspeccionar
En una lista de SharePoint de pruebas, prepara campos para identificar la solicitud, enlazar su documento y versión, indicar su estado y guardar la decisión. Define los nombres y tipos antes de configurar el flujo. Un registro por solicitud facilita reconstruir lo ocurrido sin depender de correos sueltos.
- Crea un flujo automatizado con el desencadenador de SharePoint When an item is created y selecciona la lista del piloto.
- Valida que exista un documento identificable y que estén completos los campos necesarios. Si falta información, detén el circuito de aprobación y deja una explicación visible.
- Añade Start and wait for an approval, selecciona el tipo acordado y configura los destinatarios de prueba.
- Incluye el identificador, la versión y el enlace en los detalles para que el aprobador sepa exactamente qué revisa.
- Después de la respuesta, añade una condición que distinga aprobación y rechazo. Guarda el resultado y los comentarios pertinentes en la solicitud correspondiente.
- Verifica que cada notificación describa el estado que realmente quedó registrado.
Los nombres y la ubicación de los controles pueden variar entre diseñadores. La guía oficial para crear y probar una aprobación permite contrastar cada paso. Evita ampliar el desencadenador a cualquier modificación sin revisar las condiciones: actualizar el mismo registro puede volver a iniciar el proceso.
5. Diseña qué pasa cuando nadie responde o algo falla
El plazo del negocio debe quedar explícito. Por ejemplo, el piloto puede exigir revisión en dos días hábiles, con un responsable de seguimiento. Una duración técnica de 48 horas cuenta tiempo transcurrido y no equivale automáticamente a dos días hábiles chilenos. Si necesitas calendario laboral, feriados o reglas de horario, diseña y prueba ese cálculo por separado.
Según los límites de Power Automate, una ejecución dura hasta 30 días, incluida la espera de aprobaciones. No utilices ese máximo como plazo operativo ni supongas que una espera indefinida mantendrá vivo el proceso. Además, Microsoft advierte en sus problemas conocidos de aprobaciones que una espera superior a 28 días puede fallar y dejar la aprobación en el centro de acciones. Por eso, vencer la espera no equivale a cancelar o limpiar la solicitud; el responsable debe revisar esos casos. Para circuitos más largos se necesita otro diseño.
Configura y prueba rutas para vencimiento y fallo. Power Automate ofrece condiciones de Run after para reaccionar a acciones fallidas, omitidas o agotadas por tiempo, además de ámbitos para agrupar acciones. Registra el incidente y asígnalo a un responsable. Un timeout nunca debe convertirse por defecto en “aprobado”. La documentación de manejo de errores explica estos mecanismos.
6. Valida el piloto con casos que puedan fallar
Antes de abrirlo al equipo, conserva evidencia del resultado esperado y observado para cada prueba:
- Solicitud completa aprobada: decisión y versión quedan vinculadas al registro correcto.
- Solicitud rechazada: no aparece como aprobada ni continúa por esa ruta.
- Dos aprobadores: una sola aprobación no completa una regla que exige a ambos.
- Falta de respuesta: el vencimiento produce una excepción visible, sin aprobación automática.
- Documento inaccesible o campo incompleto: el circuito se detiene con una explicación útil.
- Actualización fallida o evento repetido: el equipo puede detectar el problema sin generar decisiones contradictorias.
Comienza con un grupo reducido y compara tiempo hasta la decisión, solicitudes devueltas por información incompleta y excepciones pendientes. Usa esos datos para ajustar el proceso antes de extenderlo. Si necesitas ayuda para definir el piloto y sus controles, revisa la consultoría tecnológica de NOVVOR en Chile.
Documentación técnica consultada el 11 de octubre de 2026. Confirma licencias, límites y disponibilidad en tu entorno antes de implementar.
