Choose the object by who initiates the call
A Misc Application gives authorized internal users a code they can dial to reach a destination that may not already have a number, such as an IVR, DISA or Time Condition. Sangoma distinguishes it from a Misc Destination, which creates a target another FreePBX module can select, commonly for an already known number, feature or application.
Keep both separate from a Custom Destination. A Custom Destination publishes an existing context, extension and priority from owned custom dialplan; it does not create a user-facing access code. Start with the required caller and handoff: an internal user dialing a code, a managed module selecting a destination, or FreePBX transferring control to reviewed custom dialplan.
Treat the feature code as a numbering-plan allocation
Sangoma documents a star code or ordinary extension number and requires it to be unique across users, applications and star codes. Record the proposed digits, owning team, callers, purpose, destination, enabled state and retirement plan before saving it. Search exact numbers and patterns across extensions, queues, ring groups, parking, paging, Feature Codes, Misc Applications and outbound routes.
A familiar code is not available merely because another PBX uses it. A phone dial plan can also transform or withhold digits before they reach FreePBX. Preserve the entered value, endpoint Request-URI and loaded Asterisk match as separate evidence.
Bind one code to one managed destination
The Misc Application record contains an enabled state, description, feature code and destination. The description is administrative metadata; the code is the internal access address; the destination is the managed call-flow target. Record the destination's exact object and expected entry state rather than relying on a similar label.
A call reaching the Misc Application code does not prove the selected IVR, DISA, Time Condition, queue or other target is configured correctly. Follow the call into that object's own prompts, permissions, routes and final outcome. Do not use a broad internal-code shortcut to bypass the destination's authorization or caller-context assumptions.
Preserve the internal access boundary
Sangoma describes Misc Applications as codes dialed from internal phones. That does not make the code an authentication mechanism or authorize exposure through an inbound route, public IVR, remote tenant or untrusted device. Review the destination for toll calling, DISA access, mailbox control, forwarding changes and other privileged effects before adding a path to it.
Test from the intended extension context and one unauthorized boundary. If external callers need a supported workflow, design explicit authentication and least-privilege routing rather than importing an internal context or hiding the code in a menu.
Prove saved, generated and loaded state separately
After Submit and Apply Config, retain the saved Misc Application row, successful configuration generation and the exact loaded dialplan selected from the source extension's context. Asterisk documents dialplan show <extension>@<context> for checking the running match. Compare explicit extensions, pattern matches and included contexts when another target wins.
Do not edit FreePBX-generated output as the durable repair. If the code is absent, return to the enabled record, owning module and Apply Config result. If it is present but selects the wrong target, reconcile the saved destination and collision before reloading or restarting unrelated services.
Retest purpose, permissions and rollback
Place bounded calls from the intended internal extension and a second authorized device, then verify the exact code, loaded path, destination entry, prompts or state changes, final destination and hangup. Confirm one neighboring extension and an unauthorized boundary are unaffected. For test shortcuts into an IVR or Time Condition, retain that result as internal-path evidence rather than proof of inbound-carrier behavior.
Record the old and new allocation, phone templates, user instructions, FreePBX and Misc Applications versions, destination owner and rollback. Disable or remove unused codes through supported controls and repeat Apply Config. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.
Use a Misc Destination when another module selects the target
A Misc Destination publishes already dialable digits for an IVR, inbound route or another managed consumer. It does not give an internal user a new code to dial.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma Misc Applications user guide ↗
- Sangoma Misc Applications overview ↗
- Sangoma Misc Destinations user guide ↗
- FreePBX Misc Applications release/17.0 metadata ↗
- FreePBX Misc Applications release/17.0 dialplan source ↗
- Asterisk contexts, extensions and priorities ↗
- Asterisk dialplan inspection example ↗
- Sangoma FreePBX Misc Destinations overview ↗
- FreePBX Misc Destinations release/17.0 repository ↗
- FreePBX Misc Destinations release/17.0 metadata ↗
- FreePBX Misc Destinations release/17.0 dialplan source ↗
- Sangoma FreePBX outbound routes ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.