Identity corrections are production changes, not cleanup

Three current product changes make a usually invisible RevOps dependency easier to see. Intercom now lets authorized teammates merge duplicate users after previewing what will move, with a REST API option in Preview. Amplitude now lets analysts place selected user properties beside survey responses and carry those columns into CSV exports while hiding properties restricted by Data Access Controls. Hightouch's September changelog says audience membership can be exposed as a trait on the parent model and synchronized with other traits. Each change is useful on its own. Together they show that identity correction, context attachment and audience derivation are production data operations rather than administrative tidying.

A duplicate profile is rarely isolated. One record may hold conversations and tickets while another contains notes, attributes, audience membership or an integration identifier. Merging them changes the object through which future service, lifecycle and reporting work will run. Even when no value is deleted, lineage can be compressed: two histories become one current profile. RevOps therefore needs the same questions it would ask before a workflow release: which identity wins, what moves, what remains separately attributable, which downstream jobs will observe the change and how can an operator correct a bad decision?

Intercom's product note supplies three important controls. The operator can preview what will move, an administrator can decide which teammates may merge, and developers can call a merge endpoint through a Preview API. The preview improves human judgment, the permission creates an authority boundary and the API makes systematic repair possible. None of those controls chooses the correct surviving profile for a particular business. The company still needs a survivorship policy based on stable identifiers, account relationships, verified contact points and authoritative system ownership.

The word merge can hide multiple operations. A platform may transfer conversations, tickets and notes, select a destination profile, preserve or replace particular attributes and redirect future activity. Operators should document the observed behavior in a controlled test tenant instead of assuming that every field follows the same rule. Mutable labels such as name, email or company name are weak keys on their own. A source customer ID, product user ID, CRM record ID or other durable identifier is safer when the surrounding systems preserve it.

Amplitude shows the next stage of the chain: context is attached to an observed response. Its September 23 changelog says analysts can add project user properties to a survey's Responses table and export the same selected columns in immediate or asynchronous CSV files. This removes a manual join for common context such as plan, country or account. It also means an identity or property error can travel farther with less friction. The export can look complete while carrying a stale plan, an ambiguous account association or a property whose business meaning changed.

Amplitude says properties restricted by Data Access Controls are hidden from selection. That is an important access rule, but access and fitness are different questions. A user can be permitted to export a property that is still unsuitable for the analysis. RevOps should preserve the property definition, source, effective time and account grain used for the export. When the response is person-level but the decision is account-level, the aggregation method belongs in the analysis contract rather than being improvised in a spreadsheet.

Hightouch exposes a third layer: derived membership. Its September 2026 changelog says Customer Studio can list every audience a user currently belongs to as a column on the parent model, synchronize that list to a destination and filter on the list length. Audience membership is not a durable customer fact in the same sense as a contractual plan or billing status. It is the result of a definition evaluated against source data at a particular time. Treating the list as an ordinary descriptive field can erase the logic and freshness that produced it.

A robust identity-change contract separates stable identity, observed evidence, derived state and action state. Stable identity says which entity a record represents. Observed evidence includes conversations, tickets, responses and product events. Derived state includes audiences, scores and classifications. Action state records what a team or automation did. A merge may consolidate the first two; a context export may package the first three; a destination sync may turn the derived state into an action. Each transition needs its own owner and verification.

The release gate begins before a merge. Detect a candidate pair, capture the match reasons, measure whether any stable identifiers conflict and identify every system that references either record. If the evidence is incomplete, queue the pair for review rather than forcing a match. During approval, show the proposed survivor, the attributes and history that will move, and the values that will remain authoritative. After execution, read both the surviving record and the most important downstream destinations.

API-driven repair deserves stronger idempotency than a manual one-off. The job should carry a unique repair ID, record the source and destination identifiers, refuse already-completed pairs and stop when the target changed after approval. A retry must not reverse the direction or merge the survivor into a third record. Keep the vendor response, then independently read the final object. A successful HTTP response is evidence that the platform accepted a request, not proof that every business association now matches intent.

Downstream exports and audience syncs need a quarantine window for high-impact changes. The purpose is not to delay harmless reporting. It is to prevent a mistaken merge from immediately changing a renewal audience, support entitlement, lifecycle suppression or executive metric. Low-risk descriptive updates can flow quickly. Changes that can contact a customer, reassign commercial ownership or alter account reporting should wait for the post-merge checks defined by the business.

Measure identity operations by repair quality, not merge volume. Useful local measures include candidate pairs reviewed, conflicts that blocked automation, merges verified in destination systems, changes reversed, downstream jobs held and time to resolve an ambiguous association. Those numbers describe the organization's own process; they are not cross-company benchmarks. A rising merge count can reflect better detection or worsening upstream data quality, so the operational review must keep the causes visible.

The unifying lesson is that customer identity is an execution surface. A corrected profile changes what people see, what exports contain, which audiences evaluate true and which automated actions become eligible. Intercom, Amplitude and Hightouch now expose useful controls at different points in that chain. RevOps should connect them with a release discipline that preserves evidence before consolidation, tests the destination afterward and treats derived context as time-bound rather than permanent truth.

Related reading: Data Quality · Revenue Operations · Customer Success · Intercom · Hightouch