Best Practices

These are conventions that keep workflows easy to understand and change as they grow. None are enforced by the platform. They start to matter once a flow has more than a handful of nodes.

Name things clearly

• Give variables descriptive names (customerTier, not x). You'll read them as $(name) scattered across many nodes, so a good name is self-documenting.
• Use Log Event to record meaningful moments: a decision reached, a branch taken. It doesn't affect routing, but it makes a flow's behavior visible in reporting when you need to understand what happened on a real run.

Choose the right branching node

• Use Condition for a true/false test, and combine checks with AND/OR when a decision depends on more than one thing.
• Use Switch when one value selects among several discrete outcomes — it's clearer than a chain of Conditions, and its default exit gives unmatched values somewhere to go.

Factor out repeated logic

If the same sequence of nodes appears in multiple flows, move it into its own workflow and call it with a Logic+ Subroutine. The subroutine shares the conversation's variables, so it can read what the caller set and write results back. This keeps one copy to maintain instead of several that drift apart.

Handle the unhappy paths

A flow that only wires the happy path breaks quietly when reality diverges. Wire timeout exits on external calls, handle no-reply on prompts, and give branches a default. See Error Handling for the specifics.

Check before you publish

Run File → Verify Flow before publishing, since publishing takes effect on live traffic immediately. Verify does not execute the flow, so for a risky change publish to a number that isn't in front of customers first. You can also roll back to a previous version from File → Manage Versions (see Execution & Publishing).

Next steps