A Branch Name Can Change; Its Internal Identity Should Not Have To

Multi-location datasets are easier to maintain when every physical or service location has a stable identifier that is separate from the public business name. Without one, systems often try to match records using addresses or names that naturally change over time.

Give the identifier one job

A location ID should identify the operating unit in internal systems. It does not need to be meaningful to customers or appear on the public listing.

The value should remain stable through routine edits such as a phone change, rebrand, or correction to the street formatting.

Do not reuse IDs casually

If a branch closes and an unrelated business later occupies the same address, the new operation should not inherit the old location ID simply because the building is the same.

Likewise, a relocated branch may keep its identity if the business considers it the continuation of the same location operation.

Use IDs during imports and audits

Stable identifiers help updates target the correct profile instead of creating a duplicate. They also make it easier to compare current records with historical exports.

Map external identifiers separately

Partners and directory platforms may use their own IDs. Store those mappings without replacing the organisation's internal key.

A location ID is invisible to most users, but it creates continuity behind the scenes. Public details can evolve while the system still recognises the same real-world branch as one continuing record.

Internal IDs should survive public changes

A stable location identifier should not be built from the current business name or address because both can change. A branch can rebrand, move, or receive a new phone number while still representing the same underlying location record. An internal ID lets systems recognise that continuity even when the public fields look different.