Skip to main content
A synced trait is reachable in smart trait formulas under several names — its full path, its connection prefix, its label, and its last segment. When two traits want the same name, one has to win. Two connections can also sync a trait at the very same path: Stripe and Vitally both sync stripe.currentSubscriptionStatus. Rules read a trait by its path, so the same order decides which value a segment, flag, playbook trigger, lifecycle rule or accounts-table filter sees. A trait your product sends through Segment or PostHog is ranked by the same order when a synced trait has its name. Trait name precedence is where you decide which. Find it under Settings → Organization → Accounts.

When this matters

Most orgs never need it. It becomes relevant when a second connection starts syncing traits with the same names as one you already have — connecting Stripe to an org that already has Vitally, for example, where both sync around forty stripe.* trait names.

The default: your first connection keeps the name

With nothing configured, the connection you had first wins. That is deliberate: connecting a new platform never silently changes what an existing formula reads. The losing trait is not lost to formulas. It stays reachable at its connection-qualified full path, so a formula can always address it unambiguously:
A rule has no connection-qualified version: it reads the path’s winner. To build a rule on the other connection’s copy, move that connection up.

Two kinds of conflict

The settings panel separates them, because only one kind can be fixed by reordering. Names claimed by more than one connection. Reordering the list changes which one wins. The panel lists them and the order control is right above. Names claimed twice within a single connection. Two traits from the same connection want the same short name — a trait called country and another called stripe.country, say. Connection order cannot settle this; the winner is stable but fixed. If a formula needs the shadowed one, write it against that trait’s full path instead.

Whether winning the name changes anything

A contested name is not necessarily a problem. Two connections can sync stripe.customerId and agree on it for every account, in which case handing the name over changes nothing at all. So next to each contested name, Zudo says how many accounts the two copies actually disagree on, with an example:
The first line is the one to act on. Two systems describing the same subscription often use different words for it, and a condition written against one vocabulary stops matching when the other wins the name. Where the copies disagree, check the segments, smart traits, playbooks and flags that read that name before you reorder. Only accounts carrying a value from both connections are counted — an account only one of them knows about is not evidence either way. A value stored as text and the same value stored as a number count as agreement.

Changing the order

Move a connection up to hand it the contested names. The change applies to every formula, rule and report that reads those names.
Reordering changes which trait existing formulas and rules read, which can change the values they produce and the accounts a segment, flag or lifecycle rule matches. Check the conflict list below the control to see exactly which names are affected before you save.
Use Reset to default to go back to first-connection-wins.