---
title: "Important: Imported telephone records use a stable identifier"
manual: "Academic Profiles"
version: "3.0"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-persons:important-imported-telephone-records-use-a-stable-identifier@3.0"
source: "Changelog/2.4/Important-ImportedTelephoneRecordsUseAStableIdentifier.rst"
rendered: "2026-10-26T17:55:22+00:00"
---

# Important: Imported telephone records use a stable identifier {#important-imported-telephone-records-use-a-stable-identifier}

## Description {#description}

The import identifier of a synchronized phone-number record used to be built
from its type, so it read `phone:fe_users:<uid>` for a telephone number. That
made the identity of the record depend on a value that is now configurable, and
a reconfiguration would have created a second record instead of updating the
first one.

The identifier is now built from the **source field** of `fe_users` and never
from the type:

-   telephone numbers: `telephone:fe_users:<uid>` (changed)
-   fax numbers: `fax:fe_users:<uid>` (unchanged)

The record is matched on that identifier alone. A record still carrying the
legacy `phone:fe_users:<uid>` is recognized and renamed in one step. Where
its type is still the unselectable `phone`, it is retyped in the same step.
Where a contract carries both a legacy and a canonical record, the canonical one wins and the
legacy one is left untouched, because its provenance cannot be established
safely.

## Impact {#impact}

Two stored values change for records the synchronization writes:
`import_identifier` for telephone records, and `type` wherever it still held
`phone` or `fax` and that value is not selectable on the installation.
Anything outside this extension that keys on `phone:fe_users:<uid>` has to be
adjusted.

**No upgrade wizard is shipped, deliberately.** Existing records are repaired by
the next `academic:updateprofiles` run, the same command that wrote them,
and that run is what the affected installations already schedule. A bulk
migration would have to decide what the synchronization deliberately refuses to
decide: which of two colliding records is the real one, whether soft-deleted and
workspace rows take part, and what to write where the configured type is not
selectable.

Six cases are consequently not repaired by a synchronization run, and an
installation that needs them corrected has to act deliberately:

-   profiles carrying `skip_sync = 1`
-   frontend users that are deleted
-   profiles whose `tx_academicpersons_feuser_mm` relation was removed
-   records on page ids excluded by the configured `--include-pids` or
    `--exclude-pids`
-   installations that ran an import once and never run it again
-   records whose `fe_users.telephone` has since been emptied, which the
    synchronization removes rather than repairs

## Affected Installations {#affected-installations}

Every installation that imports profiles from frontend users with
`academic:createprofiles` or `academic:updateprofiles`.