Freeze one call, one control and one expected mode
Record the affected number, caller, timestamp and timezone, source route, expected normal or override mode, displayed mode and final destination. Name the exact Call Flow Control object rather than describing all office-hours routing as one switch. A wrong upstream inbound route, IVR branch or nested destination can bypass a correctly configured control.
Capture the FreePBX version, installed Call Flow Control module version, object index and both configured destinations. Sangoma's detailed public guide is labelled for PBX GUI version 13; the official module repository has a release/17.0 branch, but that does not prove an older screen or default code is identical on the affected host.
Prove the call entered the intended object
Follow one call from the matched inbound route or internal source into the named control and retain its Call-ID, channel path and selected generated context. Confirm that normal and override destinations have not been swapped and that a nested Time Condition, announcement, queue fallback or custom destination is not making the later decision.
Do not change both branches to a common target as a diagnostic shortcut. Use isolated temporary targets only in an approved test path, and preserve the original destinations and policy owner.
Confirm index, effective code and authorized action
Inspect the object's index and the effective enabled entry in Feature Codes. Sangoma documents a version-13 scheme in which indexes 0 through 99 extend a base such as *28; derive the installed code rather than assuming *280. Compare the exact digits the phone sends with extensions, prefixes, other controls and dial patterns, then place one authorized internal test.
If a password is configured, preserve whether the prompt appeared and whether the action was accepted or rejected. Keep access control separate from routing: a successful announcement or application return proves only that step, not a changed mode or correct destination.
Separate persisted mode, runtime branch and subscription state
Record the mode displayed by FreePBX before and after the action, the generated and loaded dialplan path, the branch selected by a real call, and the phone's subscribed BLF resource and reported state. A stale lamp, wrong monitored string or unsupported phone integration can disagree with a correct PBX mode. Conversely, a lamp change does not prove that the intended public call traversed the object.
Sangoma's Feature Codes guidance describes custom device states and Asterisk Info subscriptions. Use those read-only views and a bounded SIP trace where appropriate. Do not toggle every control, clear device state globally or infer support for a current phone from an older compatibility page.
Check Apply Config and generated ownership
After one supported Apply Config, inspect whether FreePBX generated the expected code and both branches and whether Asterisk loaded them. If saved configuration, generated output and runtime disagree, return to the owning module and Apply Config result. Do not repair a FreePBX-managed system by editing generated files or repeatedly reloading Asterisk without new evidence.
If the mode reverts after a restart or restore, compare the persisted module state, database restoration, module version and startup result. Treat recovery behavior as a separate defect from a phone lamp that fails to resubscribe.
Correct one owner and retest the whole control
Correct only the demonstrated owner: upstream route, object destinations, index or feature-code collision, password policy, authorized context, saved mode, generated configuration, loaded state, BLF subscription or phone provisioning. Retest normal and override calls through the same source, the authorized action, displayed mode, BLF indication, final destination, restart or restore behavior, and one unrelated route.
Restore the intended final mode, remove temporary traces and targets, and record the operator, reason, time and reset owner. No PBX, module, feature code, password, BLF, phone app, generated dialplan, route, destination or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma: Call Flow Control module overview, labelled for PBX GUI version 13 ↗
- Sangoma: Call Flow Control user guide, labelled for PBX GUI version 13 ↗
- Sangoma: Feature Codes module ↗
- FreePBX: daynight module repository and release/17.0 branch ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.