Skip to content
English - United Kingdom
Contact us
  • There are no suggestions because the search field is empty.

Using email aliases to prevent duplicate users

Konquest matches billings to users by email address. If the same person is going to appear under two different email addresses — for example because they'll log work in two different CRM instances, or because a migration changes which email address is used — add the second address as an email alias on their existing Konquest user. Any billings that arrive against an alias will automatically associate to that user, so no duplicate is created.

Why this matters

Whenever an integration syncs a billing, Konquest looks for a Konquest user whose email matches the owner (or beneficiary) email on that billing. If no match is found, Konquest creates a new user rather than dropping the billing — which is the right behaviour when someone genuinely is new, but it means a simple email mismatch for an existing user will quietly create a duplicate user instead of attaching to the one you already have.

This comes up most often around integration changes — moving to a new CRM instance, consolidating two instances into one, or a user picking up a second email address for a period of overlap. If the user's email is going to be different in the new source system, and you don't tell Konquest the two addresses belong to the same person, you'll end up with two separate user records: the original, and a new duplicate carrying only the billings synced under the new address.

Before it becomes a problem: add the alias ahead of time

The best time to add an alias is before the change goes live, not after duplicates have already appeared.

  1. Go to Settings > Users and open the existing user's profile.
  2. Under Email Aliases, enter the alternative address in the Email Alias field.
  3. Click Add Alias.

From that point on, any billing synced against that alias email is treated exactly as if it had arrived under the user's primary email — it attaches straight to the existing user, with no duplicate created and no manual clean-up needed. You can add more than one alias per user if there's more than one address to cover, and use Make Primary if you later want to switch which address is the user's main login.

If you know in advance that a set of users are going to change email address — for example ahead of a CRM migration — adding all the aliases up front is the simplest way to avoid dealing with any duplicates at all.

If a duplicate has already been created

If billings have already started coming in under the new address before the alias was added, you'll typically end up with a duplicate user holding just those billings. To resolve this:

  1. Go to Settings > Users and open the duplicate user's profile (the one you want to get rid of, not the one you're keeping).
  2. Click Deactivate. This frees up the duplicate's email address so it can be added as an alias elsewhere.
  3. Open the profile of the user you want to retain, and under Email Aliases, add the now-freed email address as an alias. If you'd like it to become the user's main login going forward, use Make Primary once it's added.

You don't have to open the duplicate's profile to deactivate it — on the Settings > Users list, use the search box to find them, then use the ⋮ overflow menu at the end of their row and choose Deactivate directly. This is often quicker if you already know which row is the duplicate. (The list also has a Show Inactive toggle, useful for checking a user you've already deactivated or re-activating one by mistake — the same overflow menu shows Activate for anyone already inactive.)

From that point on, any billing synced under that email attaches to the retained user — and adding the alias also triggers an automatic step that reallocates the duplicate's existing billings across to the retained user, so you don't need to move historic billings across by hand. Check the retained user's statement afterwards to confirm it reflects the combined billings as expected.

Deactivating the duplicate on its own, without adding the alias, isn't enough — it stops the duplicate from logging in, but the email address itself isn't attached to any active user, so anything synced under it afterwards won't find a match and will simply create another new duplicate rather than attaching to the user you meant to keep.

Need help?

If you're not sure which user to keep, whether reassigning a duplicate's email will affect an already-approved statement, or you have a batch of duplicates to work through following an integration change, contact your Konquest support contact with the users involved.