Name the contact owner and the consumer
Inventory the installed Contact Manager and User Management module versions and signature state, directory type, contact group, user or contact identifier and the exact consumer that needs the data. Contact Manager is a source for UCP and documented phone applications, but a visible record in the admin page does not prove that a particular user, device or client may see it.
Keep the person, SIP extension, User Management identity, Contact Manager entry and device-local address book as separate objects. Record which system owns each field, how it is synchronized and what should happen when the person changes role or leaves. Do not copy credentials or private directory fields into a troubleshooting ticket.
Preserve the three group ownership models
Sangoma documents internal groups, external groups and User Manager groups. Internal contacts obtain their defaults from User Management, while a Contact Manager edit can override those defaults for Contact Manager without changing the source User Management record. External contacts are entered directly. The default User Manager group reflects User Management users and cannot be treated like a deletable local group.
Before changing a name or number, identify the group type and whether the displayed value is inherited, overridden or local. Fix the authoritative source when every consumer should change; remove a deliberate override only after preserving its business purpose. A correct value on one screen can coexist with a stale override in another layer.
Grant group visibility deliberately
User Management controls the Contact Manager groups in which a user appears and the groups that user can view. Treat “Show in Contact Manager Groups” and “Viewable Contact Manager Groups” as different permissions. Group membership, view permission and permission to edit a UCP-managed contact are separate decisions.
Use least privilege for staff, contractors and shared devices. Test with the affected user account rather than an unrestricted administrator session. A contact returned to an administrator does not prove that a normal user has the same group scope, and an absent contact can be an intentional authorization result rather than missing data.
Verify each consumer delivery path
For UCP, verify the user identity, viewable group, widget state and the current server response before blaming the browser. For a supported Sangoma phone application, verify its account and group assignment, then preserve the device model, firmware, provisioning owner and the generated configuration. Sangoma’s DPMA Contacts guidance says adding or deleting a contact for an assigned group requires rebuilding and updating the phone configuration file; a saved server record alone therefore does not establish device delivery.
Do not transfer a UCP or DPMA workflow to an arbitrary SIP phone, mobile client or desktop softphone. Those consumers may use LDAP, CardDAV, a vendor cloud, a local address book or another integration with different caching, privacy and refresh behavior.
Treat speed dial as routing, not just directory data
The Contact Manager documentation lets an external number receive a speed-dial code and describes the *10 feature-code path plus a Contact Manager Speed Dials destination. Record the exact stored number, caller authorization, feature-code state, outbound route, number normalization and caller-ID policy before enabling it.
Contact visibility does not prove that the resulting call is authorized, routed or answered. Conversely, a working speed dial does not prove that every intended user can find or edit the contact. Test directory display and call behavior as separate acceptance cases, including a denied or invalid destination where that policy is in scope.
Stage bulk changes and protect directory data
Bulk Handler can export and import Contacts, User Manager users and groups, but those schemas and owners are distinct. Export from the installed system, retain the headers, identify internal versus external contact fields and test a small non-sensitive group before a broad import. A blank field can clear an existing value, and an internal contact reference is not interchangeable with an external phone number.
Directory data can expose names, roles, numbers, email addresses and organizational relationships. Limit exports, encrypt approved transfers, set retention and deletion owners, and remove temporary files. Sangoma warns that increasing contact and group counts can slow consumers and that some clients may not behave well above 1,000 contacts; treat that as a documentation warning, not a universal measured ceiling. Pilot the actual consumer and keep rollback evidence.
Use Contact Manager as one bounded caller-name source
Contact Manager can participate in FreePBX Caller ID Lookup, but its selected group and format, AGI result, channel name and endpoint display remain distinct evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX Contact Manager module ↗
- Sangoma FreePBX User Management group and user settings ↗
- Sangoma FreePBX UCP Contacts ↗
- Sangoma FreePBX DPMA Contacts application ↗
- Sangoma FreePBX Bulk Handler user guide ↗
- FreePBX Contact Manager module source ↗
- FreePBX CallerID Lookup repository ↗
- FreePBX CallerID Lookup metadata — release/17.0 ↗
- FreePBX CallerID Lookup generated dialplan — release/17.0 ↗
- FreePBX CallerID Lookup configuration and inbound-route hook — release/17.0 ↗
- Asterisk CALLERID dialplan function ↗
- Asterisk party-ID manipulation ↗
- Asterisk internal database ↗
- Asterisk TXTCIDNAME dialplan function ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.