The Integration Worked Yesterday. Who Notices Today?
14 July 2026Moving Contacts Without Losing Their Conversations
29 July 2026
A yacht’s displayed name is useful to a reader. It is less dependable as the sole identity of a database record. Names can change, titles can be corrected and two records can use similar wording.
For software design, give the vessel a stable internal reference and decide how that reference connects to publication records, opportunities and documents. The identifier does not have to dominate the public page. It needs to keep the relationships clear behind it.
Separate three things that look similar
| Concept | Purpose |
|---|---|
| Vessel record | The continuing identity and approved information about the yacht. |
| Listing or publication | How that yacht is presented in a particular channel or period. |
| Buyer opportunity | A particular conversation about that yacht with a buyer. |
This is a conceptual example rather than a prescribed database schema. The project may need a simpler or more detailed model. The distinction is useful because withdrawing a listing should not automatically erase the buyer’s conversation or the historical vessel information.
Test a rename
Change the display name in a test record. Then open an older enquiry, a saved shortlist and a document-generation screen. Can the team still recognise the yacht? Does a correction create an unnecessary new vessel? Can the system show the appropriate current label without obscuring the historical context?
Website addresses need their own publication rule. Do not casually change an established URL every time the headline wording changes. If a move is necessary, plan and check the route from the old address. The public link and the internal identifier solve different problems.
Our guides to listing management and buyer relationships explore the surrounding workflow. Stable identity is the quiet piece that lets those records stay connected as the business changes.