Skip to content

External Identities ​

An External Identity is a record from an external system — a user ID, a project ID, a team ID — that needs to be mapped to an entity inside SalesDash.

External identities are the bridge between provider data and your SalesDash configuration. They are why SalesDash can receive data from multiple external systems simultaneously without confusing one system's users with another's.

Why they exist ​

External systems have their own IDs for everything — users, teams, projects. For example, LeadDesk agent "12345" or a Teamleader project "project-abc". SalesDash does not assume these IDs correspond to any internal entity, or that they mean the same thing across two different systems — unless you tell it so with a matching rule.

Instead, every time a provider encounters a new user, team, or project in the external system, it creates an external identity: "provider X has an entity with external ID Y." An implementer then links that external identity to the correct internal entity in SalesDash.

Only data belonging to linked external identities is counted in metrics.

Types of external identities ​

Providers create external identities for several entity types. Each type can only be linked to the matching entity type in SalesDash:

  • Agents — the most common type; maps an external user to a SalesDash agent
  • Teams — maps an external team to a SalesDash team
  • Projects — maps an external project or account to a SalesDash project
  • Propositions — maps an external product or deal type to a SalesDash proposition

Agent identities must be linked to agents, team identities to teams, and project identities to projects. The entity must already exist in SalesDash before you can link an identity to it.

Linking external identities ​

Unlinked external identities appear at Providers → Unlinked external identities.

Create the target entities first — agents under Data → Agents, teams under Data → Teams, projects under Data → Projects — then return to the unlinked external identities list to assign them. You can filter the list by provider or entity type, and search by external name or ID.

Ignored external identities ​

Ignoring an external identity has no effect on your data — neither an unlinked nor an ignored identity contributes to metrics. The one difference: a matching rule never links an ignored identity. Otherwise, marking an identity as ignored is a housekeeping tool to keep the unlinked identities list clean. Use it for entries you have consciously decided not to map — a test account, a deactivated employee, an internal bot — so they stop appearing in the list. Ignored identities are hidden from the default view but can be surfaced by disabling the "ignored" filter.

Multiple identities per entity ​

An entity can have multiple external identities linked to it. The most common case is one identity per provider — a sales rep who uses both a CRM and a power dialer will have an external identity from each system, both linked to the same agent. But a single provider can also produce multiple identities for the same entity; for example, if an agent appears under different user accounts or roles within the same external system. Data from all linked identities is attributed to the same entity and counted together in metrics.

Matching rules ​

Often you don't need to work out a link yourself, because another external identity for the same person, team or proposition is already linked. A matching rule lets SalesDash make those links for you: for each external identity of a provider, the rule looks for the external identity it matches, and links it to the same agent, team or proposition.

How a rule finds that match is its matching strategy. Each strategy is described below.

Without a rule, SalesDash never links one external identity to whatever another one is linked to.

Setting up a rule ​

Open Providers → Unlinked external identities and choose Matching rules. Create a rule with:

  • Type — the kind of external identity to link: agents, teams or propositions, plus projects and segments when you use those
  • Provider — the provider whose external identities the rule links
  • Matching strategy — how the rule finds a match. A strategy can ask for settings of its own; those are described with the strategy.

When you save, the rule links the external identities that are already waiting and tells you how many links changed. Type and provider can't be changed once the rule exists.

What a rule does from then on ​

  • A new external identity is linked the moment it arrives, so its data counts straight away.
  • When the external identity a rule matches against is linked, relinked to someone else or unlinked, every external identity that matches it follows, together with its data.
  • A rule only links when the match is unambiguous. If its matches are linked to different agents, teams or propositions, nothing is linked — and an external identity the rule had already linked is unlinked again and appears in the unlinked list for you to handle.

A rule never changes a link made by hand or by a provider's own sync. If you relink an external identity a rule linked, the link becomes yours.

Unlinking an external identity doesn't keep a rule away from it: the next time its match changes, or someone saves the rule, the rule links it again. To keep a rule off an external identity for good, ignore it.

A rule also only matches against links made by hand or by a sync — never against links another rule made. Point each rule at the external identities that hold the real links, rather than at the ones another rule linked.

Deleting a rule ​

When you delete a rule, the links it made stay, but they stop following changes. If you created the same rule twice, the Linked external identities column in the rules table shows which one is doing the work — delete the one showing 0.

Matching strategies ​

Same external ID ​

Use this when two of your systems know the same people by the same ID. A typical case: your CRM's users are linked to your agents, and a second source — a bonus API, a payroll export — reports on the same people using the CRM's user ID. A rule on that second source links each of its external identities to the agent that the CRM identity with the same ID is linked to.

Set Match against provider to the provider that already holds the right links — the CRM in the example.

  • An external identity that belongs to a project only matches external identities in that same project.
  • If three systems share one ID, point both rules at the system that holds the real links, rather than having one rule match against the other rule's links.