See your dial plan.
Finally.

◉ WITHOUT_CFS · BUILDING

FreePBX's destination dropdowns only contain modules that already exist. So to wire a new flow you build it backward: queue first, then the IVR that points to the queue, then the time condition that points to the IVR, then the inbound route that points to the time condition.

Or you go top-down with placeholder destinations, then circle back through every node to fix them once the real downstream module exists. Miss one and a holiday call lands in terminate.

Either way, building a 12-node call flow takes an afternoon and three context switches.

And there's no undo. Every fix is a fresh manual edit through the same backward chain.

◎ WITH_CFS · BUILDING

Drop the inbound. Drop the next node, wire it. Drop the next, wire it. No node or wire is written to the PBX until you click Save.

Build the way you actually think about a call: from "the call comes in" toward "this is what answers."

Change your mind? Ctrl-Z. Linear undo on destination edits, plus an Activity Log that shows who changed what, and when.

◉ WITHOUT_CFS · TRACING

You click into Inbound Routes. Then Time Conditions. Then the IVR. Then another Time Condition. Then a Ring Group that points to a Queue. Each screen tells you one step.

To answer "where does the main number go at 6:47pm on a holiday?" you open five tabs, build the path in your head, and hope you didn't miss a CFC toggle.

◎ WITH_CFS · TRACING

Pick a DID and the full graph renders: every route, every branch, every failover. Day/night overrides are visible. Holiday conditions are visible.

Simulate a time, the graph dims the paths that wouldn't fire. Open any node's details, edit it, save. Drag to rewire. Export as PNG for the customer handoff.

◉ WITHOUT_CFS · CHANGING

A ticket asks for one small change: a new IVR option, or someone out of a ring group. You open that module in FreePBX, change it, Submit, Apply Config. The main number tests fine.

The page you edited shows that one module. It doesn't show that the same ring group is where the holiday time condition sends calls, or that a second DID lands on that IVR. On a customer you set up two years ago, you don't remember either.

Nothing looks wrong on Friday. It turns up Saturday morning, or on the next holiday, when calls take the path nobody re-checked.

◎ WITH_CFS · CHANGING

Open the module's details before you touch it. The Used by list names everything that sends calls there, so the holiday path and the second DID are on screen before you change anything.

Drag a wire to the new destination and the flow redraws with it. Nothing goes live until you click Apply Config, and the change goes in through FreePBX's own code, the same as Submit on its pages. If someone changed the same thing in FreePBX after you opened the call flow, the save stops and asks you to reload rather than write over it.

Try it in the live demo: pick After hours under Simulate time and Cloverdon's path stops at a red dot, a message that goes nowhere. Drag that port to any node and the path follows your wire.

◉ WITHOUT_CFS · VERIFYING

You changed the time condition. Now you call the main number to hear what a caller hears. Then again from a cell, because the first call landed somewhere you didn't expect and you're not sure why.

The paths you can't dial are the ones worth worrying about. You can't call the main number at 6:47pm on Christmas. So you either wait for Christmas, or you roll the clock forward on a production PBX and misroute live calls to find out.

Usually it's fine. You find out it wasn't when the customer calls you.

◎ WITH_CFS · VERIFYING

Make the change, then look at it. The flow you just edited is on the canvas, and the graph shows where a call lands.

Set the clock to 6:47pm on December 25th and the paths that wouldn't fire dim out. Nothing gets dialed, nothing on the PBX changes, and you don't wait until Christmas to learn the holiday route pointed at an extension whose owner left in March.

Wrong turn somewhere? You see it before the caller does.