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.

Handing over an external identity

Some external identities belong to a seat rather than a person: a dialer login, a phone extension, an invoicing account. When someone leaves and their successor takes over that login, relinking the external identity would move all of its data to the new agent — including everything the previous agent did.

A handover moves only the data from a date onwards. Open the agent who used the login until now, find the external identity under External identities, and choose Hand over:

• Hand over to — the agent who uses the login now. Create that agent first if they don't exist yet.
• From — the first day the new agent used the login. Today or earlier.

Data from that day goes to the new agent; everything before it stays with the previous one. That holds for data that arrives later too: a sale dated before the handover that your source reports a week afterwards still counts for the previous agent. Sales count by their sale date, calls by when they were made, activities by their moment, and periods by their start — a period running across the handover date stays whole with the agent it started with.

Moving the existing data happens in the background and can take a few minutes. Goals, agent goals, competitions and achievements that were already settled are not recalculated.

You can hand an external identity over more than once. A handover replaces every earlier handover dated on or after its own date, so all data from that date goes to the agent you choose. To correct a handover, hand it over again from the right date — also to the same agent. To move a handover to a later date, first hand the external identity back to the previous agent from the old date. The Handovers column shows who had the external identity when.

• Matching rules. External identities that a Same external ID rule linked to this one share the login, so they are handed over with it. External identities that a Same external name rule linked follow the new link entirely, as on a relink: a name belongs to a person, not to a login.
• Unlinking or relinking a handed-over external identity removes its handovers: the link then holds for all of its data again.
• Supported providers. Handovers apply to providers built on processors, and to Voys. On other providers, the data that is already there is split at the handover, but data that a later sync rewrites goes to the current agent.

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.

Links made by hand or by a sync

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.

Same external name

Use this when two of your systems share no ID, but know the same people by the same name. A typical case: your CRM's users are linked to your agents, and your dialer reports calls under each agent's full name. A rule on the dialer links each of its external identities to the agent that the CRM identity with the same name is linked to.

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

Match against provider can also be the rule's own provider. Use that when one provider knows the same person under more than one ID — two sources keyed differently, or an account recreated in the source system. Once one of those external identities is linked, the others with the same name follow it. Within one provider, unlinking an external identity whose namesake is still linked links it again straight away; ignore it to keep it unlinked.

It works like Same external ID, with these differences:

• Names match regardless of capitals and accents: "José de Vries" matches "jose de vries". Anything else must be identical — "J. de Vries" does not match "Jan de Vries".
• If the external identities sharing a name are linked differently, that name links nothing. Link those external identities by hand.
• Names change, and a rule keeps up. When a provider renames an external identity, the rule matches it again. When the external identity it matches against is renamed, the external identities under the old name and under the new name follow.
• An external identity with a blank name never matches.
• If a provider sends no name, SalesDash uses the external ID as the name, so for those external identities this rule compares IDs.