VoIP.info Guide

FreePBX Contact Manager: ownership, groups and consumer evidence

Separate User Management, internal and external contact ownership, then verify group visibility and delivery in each authorized consumer.

Reviewed 2026-10-12Current Sangoma Contact Manager, User Management permission, UCP Contacts, DPMA Contacts and Bulk Handler documentation plus the FreePBX release/17.0 Contact Manager repository reviewed October 10, 2026; several interface examples identify older PBX GUI versions and are treated as semantic evidence rather than an exact FreePBX 17 screen map; no PBX, module, directory, user, group, contact, permission, UCP session, phone application, generated phone file, speed dial, import, call or performance limit was inspected or testedIntermediateDocumentation based · not lab tested

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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.