A fund changes its name and nothing in the CRM knows about it. The announcement goes to investors, the PDS is updated, the website is amended, and somewhere in the system a campaign audience is still filtering on a text string that describes a product which no longer exists under that description.

Product lifecycle events are handled carefully everywhere except in the systems that reference the product incidentally. Reports grouped by fund name, list views built during a roadshow, marketing automation rules that fire when an activity mentions a strategy, dashboard filters written once and never opened again. None of these appear on a change checklist, because none of them were built by the people who receive the change notice.

Identifiers persist, names do not

A rename usually leaves the underlying identifier intact. The product code stays the same, the registry entry continues, and anything keyed to the code carries on working without intervention. Anything keyed to the name stops matching that afternoon.

This is the single most useful distinction available when configuring product references in a CRM. A record that stores the identifier as the key and the name as a label survives a rename with one field update. A configuration that treats the name as the key requires every dependent rule to be found and rewritten, and finding them is the expensive part, because there is no report that lists which automations contain a particular string.

Mergers behave differently. Investors move into a surviving product with its own identifier, and the original code is retired. The relationship between the two is a business fact that exists in operations and has no natural home in a CRM unless somebody builds one.

A fund that changes its name has not changed. Every report ever written about it has.

Rewriting the record or superseding it

Two approaches are available and they trade against each other cleanly.

Renaming the product record in place preserves continuity. Every meeting, campaign, and enquiry logged against the fund stays attached to it, and the pipeline reads as one unbroken history. What disappears is the point in time truth. A report run today on last year’s activity will describe conversations using a name nobody spoke in those meetings, and reconciling that report against the minutes becomes an exercise in translation.

Creating a successor record and relating it to the original preserves the history exactly as it happened. The cost is that every report, audience, and dashboard now has to account for two records where there was one, and anyone who forgets will produce numbers that are half right.

Neither approach is wrong. The failure comes from choosing without deciding, which is what happens when the change is made by whoever noticed first.

Closure leaves the interest behind

A closed fund stops accepting money and stops existing as a product. The record of who asked about it does not stop being useful. An adviser who ran due diligence on a strategy that has since closed has told the firm something about the adviser, and that information is about their mandate rather than about the fund.

Closure handling usually deletes or deactivates, because deactivation is tidy and the product is gone. The engagement history goes quiet at the same time, filtered out of every view that excludes inactive products, which is most of them by default.

Organisations record the present tense with great discipline. The ability to read their own past is something they discover has gone missing, usually while trying to explain a number to someone who was not there when it was true.

Q: Is it better to rename a fund record in place or create a new one?

Renaming preserves a single continuous history and loses the ability to see what the product was called at the time of each interaction. Creating a successor record keeps historic reporting accurate and requires every audience and dashboard to reference both. The decision should be made once and documented, not made per event.

Q: What happens to campaign history when two funds merge?

Activity stays attached to the record it was logged against, so history splits across a retired product and a surviving one unless a relationship is built between them. Fund flow reporting after the merger date will understate the surviving product if the predecessor’s history is excluded from the view.

Q: Who should be responsible for telling the CRM about a product change?

Product change notices normally reach distribution, compliance, and marketing. Whoever owns CRM configuration needs to be a standing recipient rather than someone who hears about it downstream. The task is small when it arrives with notice and considerably larger when it arrives as a broken report.

Consent attaches to the person and the communication type, not to the product, so it persists regardless of what happens to the fund. What breaks is segmentation built on product interest. Audiences filtering on an inactive product return nobody, and the contacts inside them become invisible rather than unsubscribed.