Workflows: how a flow runs

Getting here

Automate → Workflows.

Before you start

• An owner, admin or agent can create and edit a workflow. Publishing it — the thing that makes it run on live conversations — is an owner or admin action everywhere it can be done. Stopping a published workflow from the workflows list is owner/admin-only too; from inside the editor an agent can do it by changing Status to Stopped and saving — except for an Incoming Webhook workflow, which needs an owner or admin to save at all, whatever the status.
• Building and running workflows depends on your plan; see pricing. Some plans also cap how many workflows can be live at once, and publishing past the cap is refused.
• The plan is checked again every time an event arrives, so a workspace that loses access stops running its published workflows without anyone unpublishing them.

Set up

1. Click New workflow, then pick a trigger — the event that starts the run. Workflow triggers covers every one the picker offers.
2. Click + on the canvas to add the first step, and again after it for each one that follows. Conditions and variables covers forking the run and filling in {{variable}} text.
3. Click Save. A saved workflow is a Draft: it does not run on live conversations yet.
4. Open the Test tab and run it against a pretend conversation before anything real reaches it — see Test and publish a workflow.
5. Set Status to Published. Only a published workflow is ever a candidate for a real event.

How it works

• A workflow is one trigger, an optional list of conditions that gate the whole run, and an ordered list of steps.
• Only a published workflow is ever a candidate. A draft or a stopped workflow never runs on a live conversation, whatever its trigger and conditions say.
• Under Trigger Conditions, every condition must pass by default (Match all conditions); the trigger can instead be set to Match any condition. A workflow with no conditions always passes.
• When an event arrives, Inchat takes every published workflow in the workspace that uses that trigger. A trigger's own scope settings, such as a channel limit, can rule a workflow out before its conditions are read.
• Each remaining workflow is then handled on its own: conditions first, then the cooldown, then the run. More than one workflow can run for the same event, and a workflow that ran does not stop the others. Nothing sets the order between them.
• On a customer's message the more specific triggers go first — an ad, a new contact, a new conversation, a reply to a story, a payment slip. Once one of those flows has replied to the customer, or queued a reply behind a wait, the workflows on the general Message Received trigger do not run for that message.
• An Ask a Question step that is waiting for an answer gets the customer's next message before anything else. When it takes the message, no Message Received workflow runs for it.
• For a live event, a workflow that has run on a conversation does not start again on that conversation until its cooldown of 10 minutes has passed, however often the event repeats. A workflow whose conditions did not match leaves the cooldown untouched, so the next matching event starts fresh.
• A few triggers name each distinct event, and for those the cooldown does not apply — for example each milestone of a video someone is watching.
• Trigger once per contact, under the trigger's Advanced Settings, goes further: once the workflow has run for a contact, in any of that contact's conversations, it never starts for that contact again.
• Steps run in order, top to bottom.
• A fork sends the run down one lane. Condition checks its lanes from the top and runs the first whose conditions pass, or the None lane when none does. Randomizer (A/B split) picks one lane by weight, and the same contact always gets the same lane. Date & Time (business hours) takes one of its two paths.
• Whichever lane ran, the run then carries on with the step after the fork, unless a step inside the lane ended or paused the run.
• End stops the run at that step. Nothing after it runs, in its own list or in any list around it.
• Wait pauses the run. A pause of a few seconds is waited out inside the run; a longer one, or a wait until a time of day, saves the rest of the flow and resumes it later.
• Ask a Question pauses the run too. Everything after it, in its own list and in every list around it, is saved and resumes when the customer answers or when the question's own timeout passes.
• Trigger Another Workflow runs the other workflow inside the current run, as one of its steps. The other workflow must be published and must not already be in the chain, and its own trigger conditions are not checked again.
• Set exit conditions, under the trigger's Advanced Settings, ends a contact's run early: when a user sends an outgoing message, an incoming message arrives, or a user is manually assigned, the workflow's queued waits on that conversation are cancelled and a question it was waiting on is cleared, with a note left on the conversation.
• Every run that recorded a step is written to the workflow's Activity tab. Under Execution log, each run shows a pill for each step, the fork lane it took, whether it is waiting, and a red mark when it failed.
• Next to the log, Waiting now lists contacts paused inside the workflow, Not triggered lists events that reached the trigger and were turned away, and Recent runs lists when the workflow started.

When it fails

• The workflow's conditions do not match: no run starts and the cooldown is not spent. The event is listed under Activity → Not triggered as Conditions did not match, with the message text when the trigger was a message.
• Other reasons an event is turned away are listed in the same place, each in words: it ran too recently, Trigger once per contact applies, the conversation is outside the trigger's channel or entry scope, a teammate owns the thread or the AI is paused, or an earlier flow had already answered the message.
• On a thread a teammate owns, or where the AI is paused, only a workflow made entirely of record-only steps runs — tags, assignment, status, notes, tasks, waits and similar. A workflow with any message, AI reply, HTTP request or hand-off step does not run.
• The workspace's plan does not include workflows: no workflow runs on any event, and the reason does not appear on a workflow's own Activity tab.
• A step fails: it is marked failed in the Execution log, its reason is shown under the run, and the run carries on with the next step. A run with failed steps still spends the cooldown.
• Add Message Failure Branch, under Advanced Settings on a message step, changes that for a failed send: the contact follows the Failure branch instead of the steps after it. Ask a Question has its own Sending Failed arm, after which the flow carries on past the question.
• Some things end the run instead of moving on: an End step; a check before each step that finds the workflow stopped, edited or republished since the run began, or a teammate who took over the thread while the workflow holds message steps; a Wait whose time cannot be worked out; an AI Reply that finds the customer's message changed or gone; and a message whose delivery could not be confirmed either way.
• When a message's delivery could not be confirmed, Inchat also stops starting the other workflows for that event, so the customer is not sent a second copy.
• A workflow that Inchat cannot read, or that throws while it runs, costs only itself: the other workflows for that event still run.

Limits

• This article is the map of a run, not of each piece. The triggers and their settings, loop protection, testing and publishing, conditions and variables, and the AI builder each have their own article.
• Nothing orders two workflows that match the same event. Do not design one to rely on another having run first; put both jobs in one workflow, or hand off with Trigger Another Workflow, which runs inside the current run.
• The cooldown is measured from the workflow's last run on that conversation, not counted, and it is not a limit on how often a workspace's automations may run.
• Stopping, editing or republishing a workflow ends runs already in flight the next time they reach a step. The exception is a question already asked, which keeps the copy of the workflow the customer was shown, unless whoever stopped it chose to abandon its questionnaires instead — that clears the paused answers, cancels every one of its queued waits, and leaves a tagged system note so a person picks up the thread. Deleting a workflow always abandons its questionnaires this way; there is no choice on delete.
• The Execution log shows only the most recent runs, and it names each step by its type, such as assign, not by its menu label.
• Not triggered lists only events that reached a published workflow's trigger. A draft or stopped workflow is never a candidate, so nothing is listed for it until it is published.

Best practices

• Give each workflow one job and hand off between them with Trigger Another Workflow. A chain of hand-offs is limited, so read the loop article before you build a long one.
• When a workflow seems to have done nothing, open Activity before changing anything: Execution log shows what ran and what failed, and Not triggered shows what was turned away and why.
• Put the steps that must happen whatever the lane — a tag, an assignment — after the fork rather than inside every lane.

Use cases

• A new customer's first message: a flow on the new-conversation trigger welcomes them, and the general Message Received flow stays quiet on that message, so they are answered once.
• Out of hours: Date & Time (business hours) sends one path to a message and the other to an assignment, and a tag placed after the fork is applied on both.
• A follow-up a day later: send a message, add a Wait, then tag the contact — and switch on an exit condition so the follow-up is cancelled if the customer writes back.

FAQ and troubleshooting

I published a workflow and nothing happened. Where do I look?

Open the workflow's Activity tab. Execution log lists the runs that happened, Waiting now lists contacts paused inside it, and Not triggered lists events that reached the trigger and were turned away, with the reason. If the workspace's plan does not include workflows, that reason is not listed there.

Can two workflows run on the same message?

Yes. Every published workflow whose trigger, scope and conditions match runs on its own, and nothing sets their order. The exception is a message that an earlier, more specific trigger has already replied to: the general Message Received workflows stay quiet on it.

A step failed. Did the rest of the flow run?

Yes, unless the failure is one that ends the run. The failed step is marked in the Execution log with its reason and the flow moves on to the next step; a message step with Add Message Failure Branch switched on follows its Failure branch instead.

Why did the workflow run once and not again on the next message?

It is inside its cooldown for that conversation, or Trigger once per contact is on and the contact has already been through it. Not triggered says which.

What happens to people already inside a workflow if I stop or edit it?

Their run ends the next time it reaches a step. A question already asked keeps the copy of the workflow the customer was shown, so their answer still continues that copy.

Does a saved workflow run before I publish it?

No. A draft never runs on live conversations. Saving is open to an owner, admin or agent, and publishing is for an owner or admin.

Related

• Workflow triggers — The 34 events a workflow can start from — what each one actually watches, what it exposes to conditions and messages, and where it quietly does nothing.
• Conditions and variables — How a condition decides whether a workflow starts or which path a contact takes, and how a {{variable}} is filled into the text a workflow sends.
• Avoid workflow loops — What already stops a flow from re-triggering itself, and the two hard caps — on Jump To and on Trigger Another Workflow — that stop a deliberate loop from running forever.
• Test and publish a workflow — Plan a workflow's path against a pretend conversation without sending anything, then publish it — and know what Publish refuses, what it only warns about, and what it locks.
• Build a workflow with AI — Describe a flow in plain words and the assistant drafts it for you to review: the draft sits in the side panel until you put it on the canvas, nothing is saved until you press Save, and nothing runs on customers until the workflow is published.
• Assign To (human) — Hand the conversation to one named teammate, or spread it across the workspace by round robin or fewest open contacts, with an optional timeout message if nobody answers.