Shopify Flow: automatizaciones en Basic, Grow y Advanced

Postazione e-commerce con un flusso di automazione visualizzato su laptop, simbolo di Shopify Flow

Shopify Flow sirve para automatizar procesos repetitivos y deterministas sin convertir cada necesidad operativa en una app personalizada. La lógica es sencilla: un evento inicia el workflow, una o varias condiciones deciden el recorrido y las acciones ejecutan lo que has definido. La pregunta importante no es “cuántas automatizaciones puedo crear”, sino qué procesos son lo bastante claros, observables y reversibles como para merecer un workflow.

A 18 de septiembre de 2026, Shopify Flow es una app gratuita disponible en Basic, Grow y Advanced. La mayoría de las funciones son comunes, pero existen diferencias importantes: por ejemplo, la acción Send HTTP Request está disponible en Grow y Advanced, no en Basic. Los límites de uso de Flow también dependen de los límites de API asociados al plan.

Qué es Shopify Flow en la práctica

Un workflow de Flow se construye con tres elementos: activadores, condiciones y acciones. El activador es el evento que inicia el flujo; las condiciones evalúan los datos disponibles; las acciones modifican datos, envían notificaciones o ponen en marcha otro paso. Es un modelo especialmente útil cuando la regla puede expresarse con claridad: “cuando ocurra X, si Y y Z son verdaderos, entonces haz A”.

Esto hace que Flow sea muy distinto de un sistema de IA que interpreta un contexto abierto. Flow es más útil cuando necesitas un comportamiento predecible. Si un pedido cumple determinadas condiciones, puedes etiquetarlo; si una situación requiere atención, puedes enviar una notificación; si una comprobación programada encuentra registros concretos, puedes procesarlos mediante un bucle.

Para el contexto más amplio, trato la capa de IA por separado en esta guía sobre IA y automatización en Shopify. Flow no sustituye esa capa: cubre sobre todo la automatización determinista.

Basic, Grow y Advanced: qué cambia realmente

La primera distinción útil es entre las automatizaciones que permanecen dentro de Shopify y las integraciones que deben comunicarse con sistemas externos.

En Basic puedes usar Shopify Flow y crear workflows con activadores, condiciones y muchas acciones nativas. Lo que no tienes es Send HTTP Request. En Grow y Advanced, en cambio, esta acción puede enviar solicitudes a un endpoint externo. Shopify también indica que Flow aplica límites de uso distintos según los límites de API del plan.

Esto no significa que Grow o Advanced sean necesarios para automatizar. Significa que el plan se convierte en una restricción técnica cuando el workflow debe salir de Shopify y comunicarse directamente con un servicio externo mediante HTTP.

Primera regla: automatizar un proceso, no una idea

Un workflow fiable parte de un proceso que ya está definido. Antes de abrir Flow, conviene escribir la regla en una sola frase: qué inicia el proceso, qué datos importan, qué excepciones existen y qué resultado final debe producirse.

Si no puedes describir la regla con claridad, el problema todavía no está preparado para Flow. Automatizar un proceso ambiguo solo traslada la ambigüedad a un sistema que después puede trabajar de forma coherente, pero coherentemente mal.

Cuando diseño una automatización, parto de cuatro preguntas:

qué evento debe iniciar el proceso;
qué condiciones deben cumplirse antes de actuar;
qué acción es realmente necesaria;
cómo se verificará el resultado después de la ejecución.

Cinco casos en los que Flow tiene sentido

1. Etiquetas operativas para pedidos y clientes

Las etiquetas son útiles cuando clasifican casos que después deben filtrarse, revisarse o gestionarse mediante otro proceso. Un ejemplo sencillo es añadir una etiqueta a un pedido cuando se cumple una combinación precisa de condiciones, o segmentar a un cliente usando información ya disponible en el workflow.

La regla es evitar etiquetas decorativas. Si una etiqueta no alimenta una vista, un procedimiento, otra automatización o un control, solo añade ruido.

2. Comprobaciones periódicas sobre pedidos

Con un activador programado y las acciones Get data puedes crear controles periódicos. Shopify documenta, por ejemplo, workflows que recuperan pedidos sin preparar desde hace un periodo determinado, aplican una etiqueta o envían un resumen. Las acciones Get data pueden devolver hasta 100 recursos a la vez, por lo que el volumen debe tenerse en cuenta al diseñar el workflow.

3. Notificaciones internas cuando alguien realmente debe intervenir

Flow es eficaz para convertir una condición operativa en una señal. El objetivo no es enviar más correos, sino avisar solo cuando un evento requiere una decisión humana. Si cada pedido genera una alerta, la automatización simplemente ha trasladado el ruido de Shopify a la bandeja de entrada.

4. Acciones de Admin API que no tienen un bloque estándar

La acción Send Admin API request permite utilizar muchas mutaciones de GraphQL Admin API incluso cuando la operación no existe como acción dedicada de Flow. Es potente, pero tiene límites explícitos: trabaja con mutaciones, no con consultas, y no todas las mutaciones son compatibles.

Aquí hace falta más disciplina que con una acción estándar. Una modificación vía API puede tener efectos más amplios, por lo que los inputs, identificadores y condiciones deben controlarse con cuidado.

5. Integraciones HTTP con servicios externos

En Grow y Advanced, Send HTTP Request permite llamar a una URL externa. Shopify documenta una espera máxima de 30 segundos para recibir la respuesta HTTP; si no llega ninguna respuesta, se cierra la conexión y la solicitud puede volver a intentarse más adelante.

Si el objetivo es modificar datos de Shopify mediante GraphQL Admin API, Shopify recomienda utilizar Send Admin API request. La diferencia es importante: HTTP sirve para conectar Flow con un servicio externo; la acción Admin API está pensada para operaciones dentro de Shopify.

Probar antes de activar no es opcional

Flow permite probar un workflow antes de activarlo. Las pruebas pueden utilizar eventos registrados, datos reales de la tienda o eventos simulados; Shopify también puede generar eventos de prueba mediante Sidekick.

El punto clave es que una prueba no ejecuta acciones que modifiquen los datos reales de la tienda. Cuando el workflow llega a la primera acción que produciría un cambio, la prueba se detiene. En acciones que se conectan a servicios externos, Flow puede mostrar la configuración pero no simular la respuesta real del servicio.

La prueba sirve, por tanto, para validar la lógica, las variables, las condiciones y el recorrido del workflow. No sustituye una comprobación controlada del comportamiento real después de la activación.

Después de activar: revisar las ejecuciones, no solo el diagrama

Un workflow puede parecer correcto en el editor y aun así encontrarse con datos inesperados, errores temporales o límites de ejecución. Shopify registra los workflow runs como logs de ejecución y los conserva durante 14 días, lo que permite revisar qué ocurrió en cada paso.

Después de corregir la causa de una ejecución fallida, Flow también permite reintentos manuales. Un reintento reutiliza los datos del activador original, pero puede recuperar datos actualizados mediante acciones Get data y volver a ejecutar condiciones y acciones sobre el estado actual. No es necesariamente una repetición congelada de la ejecución original.

Flow también incluye el activador Workflow error occurred, que puede utilizarse para crear notificaciones específicas de error. Para los workflows que afectan a operaciones reales, un canal de error vale más que otra automatización “inteligente”.

Rate limits, timeouts e idempotencia

Shopify indica que Flow puede limitar intencionadamente la ejecución cuando uno o varios workflows consumen demasiados recursos. Esto puede provocar retrasos y, en algunos casos, errores por timeout.

Por eso un workflow debe diseñarse pensando también en la repetición. Si una misma acción se ejecutara dos veces, ¿crearía un duplicado, enviaría algo dos veces o dejaría la tienda en un estado incoherente? Si la respuesta es sí, conviene añadir un control de idempotencia: una etiqueta, un metafield, un estado verificable o una condición que impida aplicar dos veces la misma operación.

Esto es todavía más importante cuando Flow llama a sistemas externos. Un reintento no debería convertirse automáticamente en una operación duplicada.

Cuándo Flow no es suficiente

Flow funciona bien cuando el proceso es event-driven, determinista y relativamente local. Empieza a ser la capa equivocada cuando necesitas estado de aplicación complejo, autenticaciones externas avanzadas, colas, procesamiento prolongado, una base de datos dedicada, lógica multi-store o una interfaz específica para el merchant.

En esos casos, una app Shopify embedded o un backend dedicado pueden ser más limpios y controlables. Del mismo modo, si la lógica debe intervenir directamente en el comportamiento del checkout o en funciones commerce soportadas por la plataforma, el problema puede pertenecer a Shopify Functions y al desarrollo de apps custom, no a un workflow Flow cada vez más grande.

La decisión correcta no es “Flow o app” en términos absolutos. Usa Flow mientras el problema siga siendo realmente un workflow; pasa a código cuando estás intentando hacer que un workflow se comporte como una aplicación.

Flow no es una razón para eliminar todas las apps

Una buena automatización puede sustituir pequeñas utilidades redundantes, pero el número de apps por sí solo no es un criterio útil. Si una app ofrece una función estable, mantiene integraciones, aporta una UX específica o gestiona una complejidad que Flow no debería absorber, eliminarla puede empeorar el sistema.

Si estás limpiando el stack, el enfoque correcto es el que explico en esta guía sobre costes, rendimiento y sustitución de apps Shopify: primero entender qué problema resuelve cada componente y después decidir si mantenerlo, sustituirlo o eliminarlo.

El criterio que utilizo

Para mí, Flow encaja cuando puedo describir el proceso mediante una regla verificable, observar el resultado e identificar rápidamente un error. Cuando un workflow empieza a acumular excepciones, llamadas externas, dependencias y estado, deja de ser “simple” solo porque la interfaz sea visual.

El valor de Flow no está en evitar el código a toda costa. Está en mantener simples los procesos que realmente son simples mediante una herramienta nativa y legible. Cuando el problema supera ese límite, es mejor cambiar la arquitectura pronto que permitir que la automatización se convierta en el siguiente punto frágil de la tienda.