Esto es lo que la documentación no menciona hasta que usted ya ha perdido una tarde: no puede crear un flujo de proceso de negocio fuera de una solución. La mayoría de quienes lo hacen por primera vez se encuentran con este obstáculo, hacen clic por Power Automate buscando el botón correcto y asumen que la función está dañada o que su licencia es incorrecta. No es ninguna de las dos cosas. El flujo debe residir dentro de una solución desde el principio, necesita roles de seguridad asignados antes de que alguien pueda verlo y debe activarse antes de que aparezca en un solo formulario de registro. Omita cualquiera de esos tres pasos y la barra de proceso simplemente no aparecerá. El flujo existe. Solo es invisible e inútil.
Esta guía explica la secuencia completa de creación, desde abrir una solución hasta lograr que la barra de proceso aparezca en un registro de prueba, y cubre los límites y las reglas de edición que importan después de la puesta en producción.
Las tres cosas que silenciosamente inutilizan un flujo nuevo
- Los flujos de proceso de negocio deben crearse dentro del explorador de soluciones: el flujo no aparecerá fuera de él.
- Los flujos en borrador son invisibles para los usuarios; la activación es obligatoria, no opcional.
- Los pasos obligatorios de dos opciones solo aceptan Sí: un campo mal configurado bloquea la navegación legítima entre etapas.
- Límites estrictos: 30 etapas, 5 tablas y 10 niveles de ramificación; superar cualquiera de ellos hace que la validación falle al activar.
Qué hacen realmente los flujos de proceso de negocio en Power Automate y Dynamics 365
Un flujo de proceso de negocio es una barra guiada de etapas y pasos que se muestra en la parte superior de un formulario de registro en Power Apps o Dynamics 365. Su función es sencilla: obliga a introducir datos de forma coherente al guiar a los usuarios por una secuencia definida de etapas, cada una con pasos que pueden requerir completar campos específicos antes de que el usuario pueda avanzar.
La definición de flujo de proceso de negocio importa aquí porque es fácil confundir esta función con algo que no es. Un flujo de proceso de negocio controla la experiencia en un registro: qué etapas existen, qué campos son obligatorios en cada etapa y qué condiciones ramifican el flujo hacia una ruta alternativa. No sustituye los flujos en la nube ni la lógica automatizada de flujos de trabajo. Un flujo en la nube se ejecuta en segundo plano, activando y ejecutando acciones. Un flujo de proceso de negocio es lo que un usuario ve y recorre en un formulario.
Lo que proporcionan los flujos de proceso de negocio es coherencia. Sin uno, dos representantes de ventas que trabajen en la misma tabla de oportunidades de Dynamics 365 completarán campos distintos en órdenes diferentes, dejarán vacíos y enviarán registros en los que los informes posteriores no pueden confiar. Con uno activado, ambos representantes ven la misma barra de proceso y los mismos pasos obligatorios. El flujo no automatiza el trabajo: lo estructura.
Esta distinción respecto a los flujos de trabajo es importante en la práctica. Puede adjuntar un flujo de trabajo bajo demanda a una etapa del flujo de proceso de negocio, que es donde se conectan ambas funciones. Pero el flujo en sí no activa automatizaciones. Guía a las personas. El flujo de trabajo adjunto a una etapa activa automatizaciones. Mantenga estos dos conceptos separados antes de empezar a crear.
Requisitos previos antes de crear un flujo de proceso de negocio
Antes de tocar el diseñador, deben estar listos tres elementos. Si falta cualquiera de ellos, se producirán resultados confusos que parecen errores del producto, pero no lo son.
Licencia correcta para acceder a Power Platform
Se requiere un plan Power Apps por usuario, un plan Power Automate por usuario o un plan Dynamics 365 válido. Los flujos de proceso de negocio no se incluyen en todas las licencias de Power Platform. Si la opción no aparece en su menú, revise la licencia antes de asumir que se trata de un problema de permisos o configuración.
Acceso al explorador de soluciones, no a Power Automate independiente
Aquí es donde la mayoría de quienes lo hacen por primera vez pierden tiempo. La capacidad de crear nuevos flujos de proceso de negocio ya no existe en la interfaz principal de Power Automate fuera del explorador de soluciones. La función no se ha eliminado: se ha trasladado. Debe navegar a Power Apps, abrir una solución existente o crear una nueva y crear el flujo desde allí. Si intenta seleccionar la opción de flujos de proceso de negocio desde el menú izquierdo de Power Automate y no se comporta como esperaba, esta es la razón.
Una tabla asociada para que se ejecute el flujo
Cada flujo de proceso de negocio debe estar vinculado a una tabla de Dataverse (anteriormente denominada entidad en Dynamics 365). La tabla define qué registros mostrarán la barra de proceso. Las tablas estándar, como Cliente potencial, Oportunidad o Contacto, funcionan de forma inmediata. Las tablas personalizadas también funcionan, pero deben existir en Dataverse antes de poder asociarles un flujo. No puede crear el flujo y la tabla simultáneamente.
Cómo crear un flujo de proceso de negocio paso a paso
La secuencia completa tiene cinco fases: abrir una solución y asignar un nombre al flujo, añadir etapas y pasos en el diseñador, añadir ramificaciones o flujos de trabajo bajo demanda si es necesario, validar y guardar, y después asignar roles de seguridad y activar. Todas las fases son obligatorias. El error más habitual es tratar la activación como una tarea de limpieza opcional que puede hacerse después de las pruebas de usuario.
Abra una solución y asigne un nombre al flujo
Vaya a Power Apps (make.powerapps.com), seleccione Soluciones en la navegación izquierda y abra la solución donde debe residir el flujo. Si está creando una solución nueva, asígnele un nombre específico para el proyecto; volverá a ella para realizar actualizaciones.
Dentro de la solución, seleccione Nuevo y, después, Automatización y Proceso. Desde allí, seleccione Flujo de proceso de negocio como tipo de proceso. Asígnele un nombre claro: este nombre aparecerá como etiqueta en la barra de proceso, por lo que algo como «Proceso de cualificación de clientes potenciales» es más útil que «Prueba BPF v2». Elija la tabla en la que se ejecutará el flujo y confirme.
El flujo se crea en estado de borrador dentro de la solución. El diseñador se abre automáticamente. En este punto, algunas personas navegan a otra parte para revisar algo más y pierden el contexto de lo que acaban de crear. No lo haga. Permanezca en el diseñador y continúe con los siguientes pasos antes de cambiar de pestaña.
Crearlo fuera de una solución, por ejemplo, intentando comenzar desde la interfaz independiente de Power Automate sin el explorador de soluciones, es el primer error más común. Es posible que la opción no aparezca donde usted espera y, si el flujo llega a crearse fuera de una solución de algún modo (en versiones anteriores de la plataforma), gestionarlo e implementarlo después se vuelve considerablemente más difícil. Empiece dentro de la solución. Permanezca dentro de la solución.
Añada etapas y pasos en el diseñador de flujos de proceso de negocio
El diseñador de flujos de proceso de negocio presenta un lienzo con una primera etapa predeterminada. Cada etapa representa una fase principal del proceso: Cualificar, Desarrollar, Proponer y Cerrar en un flujo de ventas estándar, por ejemplo; o Recepción, Revisión, Aprobación y Finalización en un proceso de solicitud interna.
Para añadir una etapa, arrastre un componente Etapa desde el panel derecho al lienzo. Asígnele un nombre significativo en el panel de propiedades. Cada etapa del proceso necesita una categoría, normalmente correspondiente al nombre de la etapa, y una tabla. De forma predeterminada, esta hereda la tabla que seleccionó al crear el flujo, pero los flujos con varias tablas pueden asignar diferentes etapas a distintas tablas relacionadas.
Dentro de cada etapa, añada pasos. Un paso se asigna a un campo específico del registro. Si desea que el usuario complete el campo «Fecha de cierre» antes de avanzar más allá de la etapa Proponer, añada un paso dentro de esa etapa, asígnelo al campo Fecha de cierre y márquelo como obligatorio. El usuario no puede avanzar a la siguiente etapa sin completarlo.
Hay un comportamiento que sorprende a muchos equipos: los pasos obligatorios asignados a campos de dos opciones, campos booleanos de sí/no en Dynamics 365, solo aceptan Sí como valor válido. Si el campo está configurado como No, la etapa no avanzará. No es un error, es así por diseño, pero crea problemas reales cuando un campo de dos opciones significa legítimamente «este paso está completado» solo cuando se cambia a Sí. Si su proceso tiene un paso de confirmación como «Contrato recibido», el usuario debe cambiarlo a Sí para continuar. Configurarlo como No, incluso intencionadamente, bloqueará la navegación y generará un error confuso sin una explicación clara en la interfaz. Pruebe manualmente todos los pasos obligatorios de dos opciones antes de la puesta en producción.
El lienzo del diseñador tiene límites estrictos: un máximo de 30 etapas por proceso. Planifique la estructura de sus etapas antes de crear el flujo, no durante el proceso. Intentar reestructurar un flujo con más de 20 etapas posteriormente es el tipo de experiencia que genera mensajes contundentes en Slack interno.
Añada condiciones de ramificación o flujos de trabajo bajo demanda
Las ramificaciones permiten que el flujo siga una ruta de proceso diferente según los datos del registro. Si el valor de una operación supera un umbral, diríjala a una etapa de aprobación empresarial. Si el tipo de cuenta es pyme, omita la etapa de revisión legal. Para añadir una ramificación, seleccione una etapa y use el editor de condiciones del panel de propiedades para definir la lógica si-entonces.
El límite de profundidad de ramificación es de 10 niveles. En la práctica, los flujos que necesitan más de 4 o 5 niveles de ramificación suelen beneficiarse de rediseñarse como flujos independientes, con roles de seguridad que controlen qué flujo ve cada usuario; verá más información sobre esto en una sección posterior.
Pueden adjuntarse flujos de trabajo bajo demanda a etapas específicas. Se activan cuando el usuario los inicia manualmente desde la etapa. También puede adjuntar flujos de trabajo de entrada o salida de etapa, que se activan automáticamente cuando el usuario entra o sale de una etapa. Aquí se encuentra una de las sorpresas más habituales en producción: los flujos de trabajo de salida de etapa en la etapa final no se activan. La razón es mecánica: un flujo de trabajo de salida de etapa se activa cuando ocurre una transición de etapa, y la etapa final no tiene transición de salida. El flujo de trabajo está configurado, parece correcto, pero no ocurre nada cuando el usuario termina la última etapa. Si necesita activar algo al completar el proceso, use un flujo de trabajo de entrada de etapa en una etapa de finalización o active un flujo en la nube independiente según un cambio de campo realizado durante la etapa final. Diseñe teniendo en cuenta esta limitación en lugar de esperar que la plataforma la gestione de forma transparente.
La lógica de negocio aplicada mediante campos obligatorios reside en los pasos. Las reglas de negocio que cambian el comportamiento de los registros residen en reglas de negocio independientes de Power Apps. Son funciones diferentes. Confundirlas añade complejidad donde no hace falta.
Valide, asigne roles de seguridad y active el flujo
Cuando las etapas, los pasos y las ramificaciones parezcan correctos, seleccione Validar en el menú superior. El diseñador señalará cualquier problema estructural: pasos sin asignar, condiciones no válidas e infracciones de los límites de la plataforma. Corrija todos los errores antes de guardar.
Guarde el flujo. Sigue estando en borrador. Los flujos en borrador son invisibles para los usuarios. No es una recomendación flexible: es una limitación de la plataforma. Nadie ve una instancia de flujo de proceso de negocio en borrador en ningún registro. La activación es lo que hace aparecer la barra de proceso.
Antes de activar, asigne roles de seguridad. Este paso determina qué usuarios verán la barra de proceso. Vaya a las propiedades del flujo y añada los roles pertinentes: el rol predeterminado de flujo de proceso de negocio o roles personalizados según el orden del proceso de negocio y los grupos de usuarios. Un flujo activado sin asignaciones de roles de seguridad se mostrará a todos, dependiendo de la configuración del inquilino, o seguirá siendo invisible para la mayoría de los usuarios; ambos resultados son incorrectos en producción.
Después, active el flujo. El estado del flujo cambia de Borrador a Activo. En este punto, abra un registro de la tabla asociada como un usuario que tenga el rol de seguridad asignado. La barra de proceso debería aparecer en la parte superior del formulario con la primera etapa resaltada y sus pasos visibles. Esa es la señal de que funcionó. Si la barra no aparece, revise primero el estado de activación, después la asignación de roles de seguridad y, por último, si la tabla del registro coincide con la tabla asociada del flujo.
📊 En la práctica:
Después de la activación, abra un registro de prueba con una cuenta que tenga el rol de seguridad asignado, no con la cuenta de administrador que creó el flujo. A veces los administradores ven flujos que los usuarios habituales no ven, porque el acceso de nivel administrativo omite la visibilidad basada en roles. Confirme con una cuenta de usuario antes de decir al equipo que está listo.
Límites de la plataforma que rompen los flujos de proceso de negocio en producción
La mayoría de los flujos de proceso de negocio que fallan después de la puesta en producción lo hacen porque alguien los diseñó en un entorno de demostración sin considerar los límites de la plataforma. Estos límites no están ocultos; están en la documentación, pero los equipos que hacen el diseño inicial rara vez los tienen en cuenta. Cuando un flujo necesita 32 etapas o una sexta tabla, la estructura ya está creada y la conversación sobre rediseñar la arquitectura resulta incómoda.
Los límites estrictos para un único proceso de negocio son:
| Restricción | Límite | Qué se rompe al alcanzarlo |
|---|---|---|
| Etapas por proceso | 30 | La validación falla; el flujo no puede activarse |
| Tablas por flujo con varias tablas | 5 | No se pueden añadir tablas relacionadas adicionales al flujo |
| Niveles de ramificación | 10 | Las condiciones de ramificación no pueden anidarse a mayor profundidad |
| Flujos de proceso de negocio por tabla | Se permiten varios | No es un límite: es una opción de diseño |
La capacidad de tener varios flujos de proceso de negocio por tabla merece entenderse por separado. Una única tabla de Dynamics 365 puede tener asignado más de un flujo de proceso de negocio. No es una solución alternativa para alcanzar el límite de etapas: es una función de diseño deliberada. Por ejemplo, un equipo de ventas puede tener un flujo para oportunidades empresariales y otro para oportunidades de pymes, ambos ejecutándose en la tabla Oportunidad. Los roles de seguridad controlan qué flujo ve un determinado usuario. Esto importa tanto para el diseño como para la conversación sobre límites: si un único flujo se acerca a las 30 etapas, la pregunta correcta suele ser si debería convertirse en dos flujos con distintos públicos de usuarios, no si se puede ampliar el límite de etapas.
El comportamiento del flujo de trabajo en la etapa final descrito en la sección anterior pertenece a esta misma categoría de riesgo en producción. Los flujos de trabajo de salida de etapa en la última etapa no se activan. Es un comportamiento de la plataforma, no un error de configuración, y no aparece en la validación básica. Los equipos lo descubren después de la puesta en producción, cuando la acción posterior que esperaban al completar el proceso simplemente nunca ocurre. La documentación de flujos de proceso de negocio de Dynamics 365 indica este comportamiento, pero se pasa por alto con frecuencia durante la creación y las pruebas iniciales.
El modelado de procesos de negocio que ignora estos límites genera flujos que funcionan de forma aislada y fallan durante la activación o en casos límite de uso real. Cree teniendo en cuenta los límites desde el primer día, no como una comprobación final.
Cómo editar un flujo de proceso de negocio sin romper registros activos
Editar un flujo de proceso de negocio después de activarlo es una tarea habitual de administración que implica riesgos reales si se realizan cambios incorrectos en registros que ya están en curso. Esta sección es para la persona que heredó un flujo creado por otra persona y necesita mejorarlo sin empeorarlo.
Cambios seguros frente a cambios que afectan a instancias activas
Algunos cambios pueden realizarse de forma segura sin afectar a los registros actualmente en curso. Añadir una nueva etapa al final del flujo, por ejemplo, no altera los registros que ya están en la etapa 3. Añadir un paso opcional a una etapa existente generalmente no rompe las instancias activas. Actualizar nombres o descripciones de etapas es un cambio estético y no afecta a los datos ni a la navegación.
Los cambios de proceso que afectan a registros ya en curso son más arriesgados:
Eliminar una etapa en la que se encuentran actualmente registros activos
Los registros que están a mitad de un flujo y hacen referencia a una etapa eliminada pueden acabar en un estado incoherente. Los usuarios pueden observar un comportamiento inesperado en la barra de proceso.
Convertir en obligatorios pasos que antes eran opcionales
Los registros que ya han superado esa etapa no tienen problemas. Los registros que se encuentran actualmente en esa etapa pueden quedar bloqueados si el campo está vacío y el usuario intenta avanzar.
Cambiar la asociación de tabla
Esto casi siempre rompe las instancias activas de flujo de proceso de negocio en registros existentes. Evite este cambio en producción sin un plan de migración.
Para cambios estructurales importantes, como reordenar etapas, eliminar etapas con registros activos o cambiar asignaciones de campos, la opción más segura es crear una nueva versión del flujo, probarla con registros nuevos y usar herramientas de gestión de procesos de negocio para reasignar las instancias activas al nuevo flujo antes de desactivar el anterior. Esto lleva más tiempo que editar directamente el flujo activo, pero evita el tipo de estado de registro parcialmente roto que genera tickets de soporte durante una semana.
En la práctica, la mejora de procesos de negocio casi siempre se parece a esto: alguien heredó un flujo, hizo un pequeño cambio y después pasó dos horas explicando a un responsable de equipo por qué 40 registros están ahora bloqueados en una etapa que ya no existe. Los 30 minutos adicionales para una migración de versión adecuada valen la pena siempre.
Formas eficientes de gestionar varios flujos de proceso de negocio en una tabla
Cuando hay varios flujos de proceso de negocio disponibles en la misma tabla, los roles de seguridad determinan qué flujo ve cada usuario. Un usuario con el rol Ventas empresariales puede ver el Proceso de oportunidad empresarial. Un usuario con el rol Ventas para pymes ve el Proceso de oportunidad para pymes. Ambos flujos están asociados a la misma tabla Oportunidad. Ningún usuario ve el flujo del otro.
Para establecer el flujo de proceso de negocio predeterminado para una tabla, vaya al flujo y use la configuración «Orden» en las propiedades del proceso para controlar qué flujo tiene prioridad cuando un usuario tiene acceso a más de uno. El flujo con la mayor prioridad de orden se muestra de forma predeterminada; los usuarios pueden cambiar manualmente a otro flujo disponible desde el registro si su rol lo permite.
Esta es una decisión útil de diseño administrativo, no solo una opción de diseño. Un flujo de proceso de negocio personalizado para un segmento de equipo específico mantiene la barra de proceso limpia y relevante para ese equipo sin crear lógica condicional dentro de un único flujo enorme. La contrapartida es el mantenimiento: cada flujo necesita sus propias asignaciones de roles de seguridad y gestión de activación. Dos flujos son manejables. Seis flujos en una tabla justifican una conversación sobre gobernanza antes de crearlos.
Errores habituales al usar flujos de proceso de negocio en Power Automate
Sigo viendo los mismos cuatro patrones en hilos de soporte sobre flujos de proceso de negocio. Ninguno de ellos son errores de la plataforma. Todos son errores de configuración corregibles que parecen errores de la plataforma hasta que usted sabe qué buscar.
Error 1: Crear fuera del explorador de soluciones. La configuración parece funcionar: se crea un flujo, se abre el diseñador y se añaden etapas. Después, el flujo desaparece de los menús esperados, no puede implementarse en otros entornos y no puede gestionarse correctamente. La ruta de menú para automatizar flujos de proceso de negocio fuera del explorador de soluciones ya no admite la creación y gestión completas de flujos. Si se encuentra intentando crearlo aquí, deténgase, abra el explorador de soluciones y vuelva a empezar. Diez minutos ahora ahorran una tarde después.
Error 2: Olvidar la activación. Los flujos en borrador parecen completos. El diseñador muestra todas las etapas correctamente. La validación se supera. Pero cuando un miembro del equipo abre un registro e informa de que no aparece la barra de proceso, la primera pregunta siempre es: ¿lo activó? En una parte significativa de los casos, la respuesta es no. La activación no es un paso estético final. Es lo que hace que el flujo exista para los usuarios. Compruébelo antes de decir a nadie que el flujo está listo.
Error 3: Malinterpretar el comportamiento de los campos obligatorios de dos opciones. Este problema aparece después de la puesta en producción, no durante las pruebas, porque quienes prueban suelen seguir la ruta ideal en la que todos los campos se configuran con el valor «esperado». En producción, los usuarios a veces configuran valores como No y luego no pueden avanzar de etapa. El campo no está dañado. El proceso los está bloqueando por diseño. Si un paso obligatorio de dos opciones que bloquea una navegación legítima es un problema para su proceso, cambie el campo a otro tipo o convierta el paso en opcional y aplique el requisito mediante una regla de negocio.
Error 4: Diseñar más allá de los límites de la plataforma. Los límites de 30 etapas, 5 tablas y 10 niveles de ramificación son reales y no negociables. Un flujo que supera cualquiera de ellos falla la validación y no puede activarse. La optimización de procesos de negocio implica crear dentro de las limitaciones, no presionarlas esperando que la plataforma se adapte. Si el diseño de su flujo realmente necesita más de 30 etapas, debe dividirse en varios flujos con roles de seguridad que dirijan a los distintos grupos de usuarios al flujo adecuado.
Ese último punto es donde la cuestión de diseño se vuelve interesante. Cuando un proceso es lo bastante complejo como para requerir enrutamiento condicional a través de decenas de pasos, un flujo de proceso de negocio nativo no siempre es la herramienta adecuada para toda la situación. Los equipos que necesitan enviar datos de finalización de etapa a sistemas externos, como una notificación de CRM cuando una oportunidad de Dynamics 365 pasa a Propuesta o un activador de aprobación enviado a Slack cuando cambia una etapa, suelen añadir una automatización independiente sobre el flujo nativo. Para los equipos que conectan datos de etapas con herramientas externas, las más de 5.500 integraciones de Latenode cubren la brecha entre lo que gestiona el diseñador nativo y lo que debe ocurrir posteriormente en otros sistemas. El flujo nativo controla la experiencia guiada en el registro. La automatización externa gestiona lo que debe suceder en todas partes cuando cambia esa etapa.
Ahí es donde suele empezar el ticket.
