Automate Draft Orders with Shopify Flow

Use separate Kanbanify tasks to move an open Draft Order, set its marker, or assign an existing teammate. Draft tasks are different from Order tasks: Draft order stage changed supplies a text Draft ID, not Shopify Flow’s native Order reference.

Before you start

• Install Shopify Flow and Kanbanify on the same store, enable the Drafts board, and grant Kanbanify the requested Draft Order access.
• Prepare two merchant-defined stages on that Drafts board. In the destination stage’s actions menu, use Copy stage ID (also available in Kanbanify Settings). Use the ID, not the stage name. Flow has no Kanbanify stage picker.
• For assignment, choose someone already listed in Settings → Team roster. Use their roster email, not their display name or a Shopify staff-account identifier. The action does not add teammates or send invitations.
• Test with an open disposable Draft before turning on business-critical automation. Availability depends on the Kanbanify app version deployed to your store.

Connect the trigger to each action

1. In Shopify Flow, create a workflow with Kanbanify’s Draft order stage changed trigger. It starts on initial Drafts-board placement or a genuine move between Drafts stages, not on every Draft edit.
2. Add conditions restricting the workflow to your Drafts board and the trigger’s target stage ID. For an initial test, also restrict it to one disposable Draft ID.
3. Add one or more of the following Kanbanify actions. In every action’s Draft Order ID field (draft_order_id), insert the trigger variable draftOrderId through Flow’s variable selector. Do not type the variable name as literal text.

A positive decimal Draft ID or gid://shopify/DraftOrder/<id> is accepted. An Order GID, Draft display name such as #D123, admin URL, blank input or another resource’s ID is not. The Draft must still be open or invoice-sent. Removed stages, system stages, another board’s stages and invalid board context are rejected before changes. Only a confirmed absent board association can use the configured Drafts board; incomplete or malformed saved metadata is not silently replaced.

A non-looping example

For one test Draft, condition on target stage ID = your entry-stage ID. Chain:

1. Set its stage to a different destination-stage ID.
2. Set its marker to Teal / Diagonal stripe.
3. Assign an existing test teammate by email.

Bind the original trigger’s draftOrderId into all three actions. The second stage event names the destination, so it must fail the entry-stage condition rather than loop. The marker action runs after the stage action and overrides any destination default marker. These actions are independent, not one transaction: inspect each action’s outcome.

Enable the test workflow, move that Draft into the entry stage, then inspect Flow’s run history and reload Kanbanify to verify the destination stage, marker and assignee on that same Draft. Check action outcomes, not just that a workflow started. Disable or remove the test workflow before removing its disposable data. Avoid rules that move a Draft back and forth.

What success and retries mean

• Draft stage action success confirms saved placement only. A configured destination default marker is saved with the stage; without a default, the existing marker is preserved. Assignee and unrelated metadata are untouched.
• Manual sort cleanup, automatic stage tags and downstream trigger submission are best-effort after that save. Failures do not undo the stage or turn the action into a failure. Failed new-tag addition skips removal of old stage tags; failed removal can leave both tags. Check the card and tags when these matter.
• A valid request for the already-saved stage succeeds without changes. It does not repair earlier sort/tag failures or replay a trigger, including after a lost save response.
• Repeated valid marker or assignee actions safely write the same values. They do not change stage, tags or manual sort placement. The latest successful write wins.
• Validation or lookup failure makes the action fail before writes. A rejected primary save preserves the previous state; a connection lost after sending a save may hide a completed write. Reload the Draft before deciding what to do. There is no automatic rollback or compensation.
• A submitted trigger does not prove a workflow ran. Kanbanify provides neither guaranteed delivery nor exactly-once workflow execution, concurrent deduplication or automatic replay.

Board moves and existing Order stage actions have different failure boundaries. A board move can save its stage and still fail on required sort cleanup (without a trigger) or on tags (after attempting its resource’s trigger). The existing Order stage action can stop before its trigger after a saved stage if sort cleanup or a thrown tag request fails. A same-stage retry does not repair or replay those submissions. Do not apply the Draft Flow action’s placement-success rule to these other entry points.

When a Draft becomes an Order

Completing a Draft in Shopify never starts the Draft trigger. Normally, Kanbanify copies its marker/assignee, places the resulting Order in the Orders board’s first stage, handles stage tags and Draft cleanup, then attempts the Order stage-changed trigger once.

There is a retained retry limit: if the Order stage saves but conversion tag handling or cleanup fails before submission, a later successful retry can see that saved stage and submit zero Order triggers. Conversion has no recovery or replay guarantee. Verify the resulting Order and Flow history; do not rely on conversion for guaranteed one-time notifications.

Keep Order and Draft workflows separate

Existing Order task names and native Order bindings remain available. The Order trigger additionally provides orderName and orderAdminUrl; its original fields remain. Same-stage Order board requests no longer start Flow. Keep an existing Order workflow as an independent check when introducing Draft automation.

The Draft trigger offers Draft ID/name/admin URL, board, source/target stage and captured assignee context. Optional text may be empty and unavailable positions are -1; initial placement has no source stage. It does not expose a typed Draft reference, arbitrary Draft data, notes or tags. Captured assignee fields are not refreshed by an assignment later in the workflow.

There is no combined Draft action, board-transfer action, or separate Draft action for sort, tags, completion, due date or notes. Marker, assignee, reorder/sort, tags, notes, completion and conversion do not start the Draft stage trigger. Completing Drafts from Kanbanify or its Flow actions is unsupported.