Automatizar pedidos preliminares con Shopify Flow

Utiliza tareas independientes de Kanbanify para mover un pedido preliminar abierto, cambiar su marcador o asignarle un compañero existente. Las tareas de pedidos preliminares son distintas de las de pedidos: Draft order stage changed proporciona un ID de texto, no la referencia nativa de pedido de Shopify Flow. Los nombres de las tareas se muestran aquí tal como los declara Kanbanify.

Antes de empezar

• Instala Shopify Flow y Kanbanify en la misma tienda, activa el tablero de pedidos preliminares y concede el acceso solicitado a esos pedidos.
• Prepara dos etapas personalizadas en ese tablero. En el menú de acciones de la etapa de destino, copia su ID; también está disponible en Configuración de Kanbanify. Utiliza el ID, no el nombre. Flow no ofrece un selector de etapas de Kanbanify.
• Para asignar, elige a alguien que ya figure en Configuración → Equipo. Usa su correo en la lista de Kanbanify, no su nombre ni un identificador de cuenta de personal de Shopify. La acción no crea compañeros ni envía invitaciones.
• Prueba con un pedido preliminar abierto y desechable antes de activar automatizaciones importantes. La disponibilidad depende de la versión de Kanbanify desplegada en tu tienda.

Conectar el activador a cada acción

1. En Shopify Flow, crea un flujo con el activador de Kanbanify Draft order stage changed. Se inicia con la colocación inicial en el tablero o un cambio real entre etapas, no con cualquier edición.
2. Añade condiciones para limitarlo al tablero y al ID de la etapa de destino del evento. Para la prueba inicial, limítalo también al ID de un único pedido preliminar desechable.
3. Añade las acciones necesarias. En el campo de ID del pedido preliminar (draft_order_id) de cada acción, inserta la variable draftOrderId del activador mediante el selector de variables de Flow. No escribas el nombre de la variable como texto literal.

Se acepta un ID decimal positivo o gid://shopify/DraftOrder/<id>. No se acepta un GID de Order, un nombre como #D123, una URL de administración, un valor vacío ni el ID de otro recurso. El pedido preliminar debe seguir abierto o con factura enviada. Se rechazan etapas eliminadas, etapas del sistema, etapas de otro tablero y contextos de tablero no válidos antes de modificar datos. Solo una ausencia confirmada de asociación permite utilizar el tablero de pedidos preliminares configurado; los metadatos incompletos o incorrectos no se sustituyen silenciosamente.

Ejemplo sin bucles

Para un único pedido preliminar de prueba, añade la condición ID de etapa de destino = ID de tu etapa de entrada. Encadena:

1. Cambiar su etapa a un ID de destino diferente.
2. Aplicar el marcador Teal / Diagonal stripe.
3. Asignar un compañero de prueba existente mediante su correo.

Inserta el draftOrderId del activador original en las tres acciones. El segundo evento tendrá como destino la nueva etapa y no deberá cumplir la condición de entrada. El marcador explícito se aplica después del cambio de etapa y sustituye al predeterminado de destino. Las acciones tienen resultados independientes; no forman una transacción única.

Activa el flujo de prueba, mueve ese pedido preliminar a la etapa de entrada y consulta el historial de ejecuciones de Flow. Recarga Kanbanify y comprueba la etapa, el marcador y la asignación en el mismo pedido. Comprueba cada acción, no solo el inicio del flujo. Desactiva o elimina el flujo de prueba antes de retirar los datos desechables. Evita reglas que muevan el pedido repetidamente entre etapas.

Qué significan el éxito y los reintentos

• El éxito de la acción de etapa confirma solo la colocación guardada. El marcador predeterminado se guarda con la etapa si está configurado; si no, se conserva el marcador actual. No cambia el responsable ni otros metadatos.
• Después del guardado, la limpieza del orden manual, las etiquetas automáticas y el envío del activador son de mejor esfuerzo. Sus fallos no deshacen la etapa ni convierten la acción en un error. Si falla añadir la etiqueta nueva, se omite quitar las anteriores; si falla quitarlas, pueden quedar ambas. Revisa la tarjeta y las etiquetas cuando sean importantes.
• Una petición válida para la etapa ya guardada termina sin cambios. No repara fallos anteriores de orden o etiquetas ni vuelve a enviar el activador, incluso tras perderse la respuesta de un guardado.
• Repetir una acción válida de marcador o responsable escribe los mismos valores de forma idempotente. No cambia etapa, etiquetas ni orden manual. Prevalece la última escritura correcta.
• Un fallo de validación o consulta rechaza la acción antes de escribir. Un guardado primario rechazado conserva el estado anterior; perder la conexión después de enviarlo puede ocultar un guardado realizado. Recarga el pedido antes de decidir cómo continuar. No hay reversión ni compensación automática.
• Enviar un activador no demuestra que se ejecutó un flujo. Kanbanify no garantiza entrega, ejecución exactamente una vez, deduplicación simultánea ni reproducción automática.

Los movimientos del tablero y la acción de etapa de pedidos normales tienen límites diferentes. Un movimiento del tablero puede guardar la etapa y fallar al limpiar el orden manual obligatorio (sin activador) o al procesar etiquetas (después de intentar el activador del recurso). La acción existente de etapa de Order puede detenerse antes del activador tras guardar la etapa si falla la limpieza del orden o una petición de etiquetas lanza un error. Un reintento en la misma etapa no repara ni repite esos envíos. No apliques la regla de éxito por colocación de la acción Draft a estas otras operaciones.

Cuando el pedido preliminar se convierte en un pedido

Completarlo en Shopify nunca inicia el activador Draft. Normalmente, Kanbanify hereda el marcador y el responsable, coloca el Order resultante en la primera etapa del tablero de pedidos, procesa etiquetas y limpieza del Draft y después intenta una vez el activador de etapa de Order.

Existe una limitación de reintento: si se guarda la etapa del Order pero fallan las etiquetas de conversión o la limpieza antes del envío, un reintento posterior correcto puede detectar esa etapa y enviar cero activadores Order. La conversión no ofrece recuperación ni reproducción garantizada. Comprueba el pedido resultante y el historial de Flow; no dependas de la conversión para notificaciones garantizadas una sola vez.

Separar los flujos Order y Draft

Se conservan los nombres de las tareas Order existentes y sus referencias nativas. El activador Order añade orderName y orderAdminUrl sin quitar sus campos anteriores. Las peticiones a la misma etapa del tablero Order ya no inician Flow. Mantén un flujo Order existente como comprobación independiente al introducir la automatización Draft.

El activador Draft incluye ID, nombre y URL de administración, tablero, etapas de origen/destino y responsable capturado. El texto opcional puede estar vacío y las posiciones no disponibles valen -1; la colocación inicial no tiene etapa de origen. No ofrece referencia Draft tipada, datos arbitrarios, notas ni etiquetas. Los datos del responsable capturado no se actualizan por una asignación posterior en el flujo.

No hay acción Draft combinada, traslado entre tableros ni acciones separadas para orden manual, etiquetas, finalización, fecha límite o notas. Los cambios de marcador, responsable, orden, etiquetas y notas, así como la finalización y conversión, no inician el activador de etapa Draft. No se admite completar pedidos preliminares desde Kanbanify ni desde sus acciones Flow.