FreePBX feature codes

Treat codes as part of the numbering plan

Feature Codes enables or disables supported functions and assigns the digits users dial to invoke them. Familiar star codes are defaults, not universal constants. A local administrator or provider template may have changed them.

Maintain one list covering extensions, ring groups, queues, parking and feature codes. A code that overlaps an extension or a dial pattern creates ambiguous behavior that users experience as a broken feature.

Change one code with its dependants

Inspect the Feature Codes module, record the current value and the feature’s enabled state, then choose an unused code. Apply the change and update provisioned phone buttons and user instructions together. Do not assume an old BLF label automatically follows the new code.

A dial action and a state subscription can differ. For a DND or hours button, verify both what pressing the button does and what the lamp means afterward.

Verify context and access

Dial the code from an authorized internal extension, then confirm that an unrelated public IVR cannot expose privileged functions. A hidden menu option is not authentication. Disable functions that the deployment does not use, especially ones capable of starting outbound calls.

If the phone sends nothing, inspect its local dial plan. If the PBX receives the digits but chooses the wrong application, inspect the generated dialplan and numbering overlap. Keep those observations separate.

Inspect effective state before editing

Record the feature's enabled state, default and user-defined code, and owning module before changing it. FreePBX modules register feature codes and administrators can change or disable them, so a vendor quick-reference card or another PBX's defaults are not authoritative. Compare extensions, direct-to-voicemail prefixes, internal destinations and outbound patterns for exact and pattern collisions.

After one supported Apply Config, inspect the running Asterisk dialplan read-only in the source extension's context. Do not edit generated FreePBX files: if the expected entry is absent, return to the owning module, Feature Codes state and configuration-generation result. The focused feature-code diagnostic keeps endpoint digits, runtime selection and later feature state separate.

Roll back coherently

Restore the previous code, apply the configuration and refresh affected device templates if the pilot fails. Tell users which behavior changed. Use the configuration lifecycle to keep future code changes reviewable.

Do not treat every pickup code as the same feature

General pickup requires overlapping call and pickup groups; directed pickup identifies an extension and context; a ring-group number and a BLF key can add other managed paths. Use the call-pickup diagnostic to preserve the exact path and ringing channel.

Keep in-call transfer codes distinct from phone transfer actions

A blind or attended transfer initiated by an Asterisk in-call feature code is not automatically the same as a phone Transfer key, BLF shortcut or native SIP REFER. Use the FreePBX transfer diagnostic to prove the active path, party permission, context and final bridge.

Allocate custom destination codes through Misc Applications

A Misc Application adds a unique user-dialable code for a managed FreePBX destination. Treat it as a numbering-plan allocation: prove the endpoint digits, effective code, collision search, destination, internal access boundary and loaded dialplan before publishing it to users.

Keep the Wake Up Calls code inside its authorization boundary

The Wake Up Calls guide separates the configured feature code from operator mode, permitted scheduling identity, selected destination and the later originated call.

Distinguish FreePBX codes from Asterisk custom bridge features

The custom dynamic features guide inventories built-in codes, application-map items, feature groups and their separate authorization boundary.