Conversation Flows on a Channel That Has No Flow Builder

Every product in this category eventually shows you a canvas: boxes joined by arrows, a decision diamond, a branch for yes and a branch for no. It demos beautifully and it screenshots well in a client deck.

There is no canvas here. That is a deliberate absence, and the argument for it is worth making properly rather than filed under "features we lack".

What a flow diagram quietly assumes

A branching flow assumes the system controls when the next step happens. Step three fires after step two, possibly after a delay you set.

On Instagram it cannot. You may reply to a direct message for twenty-four hours after their last message, and only another message from them restarts that clock. There is no delay node that can be honoured, because the right to send at all expires and only the other person can renew it.

So a five-step flow is really: one message you are certain to be allowed to send, followed by four you may or may not be. Drawing them as equivalent boxes is the part that misleads.

What replaces the canvas

Several independent automations, each triggered by something the person actually did, with no shared state between them.

That sounds worse and behaves better. From the customer's side it reads as a conversation, because each of their messages gets a relevant answer. From your side there is no orchestration to debug, no stuck contacts sitting in step four of a flow nobody remembers building, and no state to go stale.

Design the one message you are certain to send

Since the first reply is the only one guaranteed, almost all the craft goes there. It has four jobs and they fit in a short message.

That fourth item is the only "branch" that exists, and it is not yours — it is theirs. Design for it rather than around it.

What handles the cases a branch would have handled

Most of what people draw branches for is already handled by checks that run before every send, deterministically, without anybody drawing anything.

• They commented twice — dedupe sends one reply, not two.
• They are mid-conversation with you — takeover means the automation stood down the moment you replied by hand, and stays down.
• They just got a message — cooldown stops a second arriving a minute later.
• It is the middle of their night — quiet_hours holds it.
• The window shut — window refuses, and records that it did.

A branch for each of these is a branch you would have had to design, test, and maintain. These are the same for everybody and cannot be forgotten.

When several automations could match

If two automations could fire on one comment, the practical answer is not a priority system — it is scoping. Attach each automation to specific posts under Advanced, so the same word can mean different things under a pricing post and a launch post without either one guessing.

Where they do overlap, dedupe and cooldown stop the person receiving two messages, so the failure mode is a slightly wrong reply rather than a barrage.

The honest cost of not having a canvas

Two real things you give up.

You cannot show a client a diagram. For agencies whose deliverable has been a flow chart, that is a genuine commercial loss, and it is worth knowing before buying.

And you cannot express "if they say yes, send A; if no, send B" as one object. You express it as two automations keyed on different words, which is more configuration in exchange for less state.

Whether that trade is right depends on what you are building. If your funnel genuinely needs a conditional tree six steps deep, this is not the tool, and the honest review says so.

What to build instead, this week

One automation on your most-commented post. A negative keyword list. Test on yourself, then live. If the replies start needing a second message, write a second automation keyed on what people actually say next — which you will know by then, because you will have read it.

The full argument about sequences is in the sequence design post, and the mechanic underneath all of this is comment to DM.