FreePBX contact missing or stale: trace source, scope and delivery

Describe one contact, one viewer and one consumer

Record the time and timezone, installed Contact Manager and User Management module versions, affected contact, expected group, viewing user, exact consumer and symptom. “Missing everywhere,” “wrong only in UCP,” “stale only on one phone,” “search cannot find it” and “the speed dial calls the wrong destination” are different failures. Compare one known-good contact in the same group without exposing private directory data.

Preserve the current record and permissions before editing. Do not rebuild every phone, delete a group, reimport the directory or clear application data merely because one display is stale.

Find the authoritative record and any override

Classify the group as internal, external or User Manager. For an internal contact, compare the User Management value with any darker, explicit Contact Manager override documented by Sangoma. For a User Manager group, change the User Management source rather than trying to edit the derived group as though it were local. For an external contact, confirm that the direct Contact Manager record contains the intended number and group.

If Bulk Handler created or changed the record, preserve the import file, object type, headers and result. A syntactically accepted row does not prove that it referenced the intended User Management user or populated the consumer-visible field.

Prove group membership and viewer scope

In User Management, compare the affected user’s groups, “Show in Contact Manager Groups” selection and “Viewable Contact Manager Groups” selection. Then reproduce with that user’s own UCP or phone identity. An administrator’s unrestricted result is not a valid control for a restricted user.

If the contact is visible to one user but not another, remain on group and permission inheritance until the difference is explained. Avoid granting a broad group merely to prove the data exists; use the smallest approved permission and verify that unrelated groups remain hidden.

Trace the selected consumer after the server state is correct

For UCP, confirm the current login identity, authorized group and Contacts widget result, then use a fresh session only if session or client state is the demonstrated boundary. For a supported DPMA phone contact application, compare the assigned group with the generated configuration and device fetch. Sangoma says contact additions and deletions require a rebuild and update of the phone configuration file, so retain both the rebuild result and the phone’s post-update view.

A SIP registration or successful call does not prove directory synchronization. Do not factory-reset a phone or expose new provisioning services to work around an unproven group, permission or generated-file problem.

Separate search, display and dialing

Verify the exact search string and displayed field separately from the number selected for dialing. A contact can be visible but not match the consumer’s search behavior, or display the expected name while carrying a stale phone value. If a speed dial is involved, preserve its *10 code, generated destination, outbound route and authorization evidence.

Follow a test call only after directory selection is correct. Record number normalization, selected route, caller identity, provider response and answer as separate stages. Changing codecs, NAT or RTP cannot repair a contact that never reached the consumer or selected the wrong number.

Correct the first missing boundary and retest lifecycle

Change only the demonstrated owner: User Management source, Contact Manager override or external entry, group membership, view permission, import row, generated phone file or consumer state. Keep the prior value and a rollback trigger. Where a user changed role or left, verify removal from both source and every authorized consumer rather than only hiding one display.

Retest create, change and delete for a representative contact, then sign out and back in and perform the documented phone rebuild/update only where that path applies. Confirm intended visibility, absence from unauthorized users, correct displayed fields and an approved call result if dialing is in scope. No PBX, module, directory, user, group, contact, permission, UCP session, phone application, generated file, speed dial, import, call or performance result was inspected or tested for this guide.

Escalate identity-wide symptoms before widening contact scope

If the same user cannot authenticate to UCP or lacks several unrelated UCP features, follow the User Management and UCP access diagnostic before changing Contact Manager visibility. Keep a contact-source or delivery failure separate when login and effective feature authorization already work.