I'm building a user license portal, store, SSO, and mini CRM and admin for internal people to manage those users for a niche 3D software company, similar to Autodesk. Licenses are sold to both companies and single users. What is the best way to avoid company data duplication

  1. Not all companies have tax Id and we do not collect tax. Product is international
  2. Website was an option, but most single users do not have websites, only some* companies.
  3. A user might buy a product in "France" while another one in the "UK" at the same time and they don't know about each other but they are from the same company
  4. Some very large companies have branches in different countries or cities
  5. User login is used with email address + password only
  6. The majority of customers are single users without any company
  • 2
    What are the problems you would run into if two users enter the same company details and those details get stored separately? Commented Feb 19, 2019 at 7:24
  • Yes. Two users buy a product from the same company in different locations, they don't know about each other's purchases, so two company accounts are created. Commented Feb 20, 2019 at 18:10
  • @DanielVianna: you did not answer Bart's question. What are the problems you would run into by having the same company account created twice?
    – Doc Brown
    Commented Feb 20, 2019 at 19:34
  • CRM admins do not care about data, so if something goes wrong they will blame me for system problems or duplicates Commented Feb 20, 2019 at 21:24

2 Answers 2


Your CRM reflects your knowledge about each buyer or user of your product at a certain point in time. When the number of entries in the CRM grows beyond a certain limit (somewhere between 10 and 50), you will not be able to affort to keep that information always up-to-date. You won't get automatically informed if a person associated to a CRM quits, changes the company, changes his/her name or working location. You may even miss the information if the company vanishes, rebrands, relocates, merges with another company or splits up into many (though most companies invest some effort to inform their business partners about such actions).

The point of this is: you cannot avoid data duplication in a CRM completly, because data duplication can be an effect caused by unavoidable obsolescence of the data.

If user Alice from company X buys your product today, and Box from company Y buys your product next month, you may not know if X and Y are really different companies, or if X was just rebranded to Y, or X is just a sub-department from Y, or something different.

The question you should ask yourself here: Why is it really important to avoid data duplication?

Note that for the restricted use case of license purchasing, or even contracts, data duplication is not an issue. Your customers identify themselves as a company or individual at the point in time when they buy the license or sign the contract. If you have two buyers from the same company, it does not make difference from the contract's perspective if you store their data once or duplicated. If there are license-related actions to take at a later point in time which involve customer data, and the customer forgot to inform you about changed contact data, it is usually not a real issue to use the old contact information to find out about the new one.

Duplicate data will only become a problem when you, for example, have dozens of contacts from the same company in your CRM to manage, and then you need to apply changes to the company data "as a whole" - rebranding, relocation etc., what I mentioned above. Avoidance of data duplication will help to make the management of this data more convenient to some degree, but it seldom needs to be a top-priority goal - it is only a matter of convenience, no less, no more. In reality, you can often live with a certain redundancy. Just make it clear for everyone who works with that CRM that entries in there reflect a historical customer knowledge from the past.

Best you can do here is

  • give each entry in your CRM database a timestamp which is transparent to the users, so they can see how "up-to-date" the information is

  • have only trained users enter / update information in the CRM, and make sure they double-check for the existence of a company in the CRM database

  • whenever your customers send you an update about their personal or business data, make sure your CRM users use that as a occasion for not only updating their data, but also double-check related data. For example, encourage them to make a web search to check the business data

  • in your CRM software, provide tools for finding already existing data, and for restructuring persons, companies and their relationships. It should be easy, for example, to assign or reassign a company to a person whenever your users get aware the old assignment is not up-to-date any more.

So in short, your users have to learn to live with the fact that some degree of duplication is unavoidable, and that only a certain effort to fight the duplication is worth the hassle.

  • Hi Doc. It's not just CRM. We have a fully integrated system. User creates login via SSO using email as primary address and company then user buys a desktop software license, we fulfill the order giving the user a dongle license for desktop software, then we have a mini CRM/ERP to manage these people, licenses and purchases. Think of a mini hubspot + shopify + SSO and something like Adobe Cloud for Adobe employees to check what is going on with user accounts and dongles Commented Feb 20, 2019 at 18:15
  • 1
    @DanielVianna: my answer focusses on the process and its caveats, not on the specific technical solution. Replace "CRM" by "user database inside your system", if you like, the answer will stay the same: you are probably trying to solve a problem you cannot solve completely, so don't take it as a top priority - solve it only to the degree you really need to solve it, not more.
    – Doc Brown
    Commented Feb 20, 2019 at 19:35

The obvious solution to me would be to have a shared database with tax info for all countries. Maybe you could use local settings for tax settings specific to the country where the software is installed, but I think it may surprise you to know that the tax laws within the same country can vary according to the product, so it would be a mistake to think that one country = one tax setting.

The shared database can be installed at one client and shared via VPN or the shared database can be in a cloud. Regardless you would be wise to create an id for each installation/userbase and use this key in all your tables so that the users of one installation won't see the users of another.

The old school approach would be to install a single database for each individual installation, but this is a maintenance nightmare and it will cause you serious issues for future updates. The best you can hope for is to save the information in one place and provide a convenient means for administrators or superusers to change this information.

Good luck!

  • We don't charge tax unless the sale is done in Canada. 90% of users are outside Canada. We cannot have ID of installation, because the Dongle system is not connected to the internet, we are trying to solve this with a new license model (cloud) but this can only be done until we create the system basis to replace the old one. There is also a problem that a lot of users go offline for a long time and they only have data on cellphone (locations which internet connection is bad for computers). Commented Feb 19, 2019 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.