Avoid duplicate contacts – Without central contact management

Central contact management is a great idea, but it’s often difficult to achieve in practice. What if everyone could keep using their preferred systems while still avoiding the hassle of duplicate contact entries?

Duplicate contact management isn’t just a problem within the same tool (e.g., CRM); it often spans across different systems, each with its own purpose and user base, like M365, CRM, and ERP. As digitalization progresses, the way we maintain identity data and contacts is evolving. Some systems seamlessly share contact information, while others don’t, leading to inconsistencies and the need for manual updates.

The aim of this article is to present a solution for avoiding duplicate contact maintenance – an alternative approach to decentralized maintenance.

Duplicate identities exist within a system but also across system boundaries.
Can duplicate contact maintenance be avoided?

Why centralized contact management?

Introducing a centralized contact management system goes hand in hand with the desire to maintain control over the data.

One goal is certainly to establish a standardized process for recording and storing data.

However, the second and often primary goal is to avoid duplicates. Duplicates can cause confusion, appear identical yet differ in subtle ways, and if one contact is deleted, the other might still remain. Most importantly, managing duplicates requires double the effort, whether within the same system or across different ones.

Dual identity management – what does that mean?

The question can be answered in two ways. In most cases, the duplicate creation of a contact within a system (often CRM) is meant. We will leave this ‘internal problem’ of centralized contact management aside here – duplicates within a system are easier to track down.

However, large organizations use a variety of systems that store personal data for different purposes.

It is often the case that different departments record the same identity data. These can be suppliers, customers, partners, but also internal and external employees.

Examples:

• An HR system (HR department) records internal employees who are on a payroll with extensive personal data.
• Entra ID and M365 (IT department) record internal and external employees for access and authorizations. In addition, employees, suppliers, customers and partners without M365 access can also be recorded as contacts
• A global address list (Central Services department) records internal and external employees to provide a telephone book and organizational data.
• A CRM system (sales department) records interested parties and customers, i.e. mostly external contacts, in order to provide customers with regular support.

But what do you do if, for example, CRM contacts are to be made available in Microsoft Teams and there are also contacts there?

The illustration shows an example of the situation described above. Different departments use different systems. They use and sometimes maintain the same identities for different purposes.

What problems arise from double contacts?

There are two types of problems associated with the duplicate maintenance of identities:

• Problems within one system, i.e. classic duplicates, and
• Problems caused by duplication across different systems.

Double contact maintenance within a system – what are the consequences?

The challenges within a system are usually organizational. CRM systems are created twice because

1. Previously not searched whether the contact already exists
2. A different spelling was used and duplicates were not recognized.

The resulting practical problems are:

• Multiple approaches to the same contact by different employees
• Repeated contact without new information
• Two sales employees offer the same customer a similar product
• Same message to the customer via different channels (email, phone, social media)
• Uncoordinated follow-up after initial contact
• Repeated offer submission without reference to previous interactions
• Multiple customer surveys, feedback requests or duplicate invitations

Duplicate identities in multiple systems – who is responsible?

If two departments maintain the same data and have a linked process, the following problems arise:

• Duplicate creation costs multiple times and leads to different data quality
• Two different departments send the new employee or customer a welcome message after registration
• Overlapping communication between marketing, sales and customer service
• The new colleague cannot work: Account exists in HR, but not yet in IT
• Deletion: the contact is deleted in one system but still exists in the other
• Unclear responsibilities – is everyone responsible for data maintenance, a specific department, or ultimately no one?

What are the negative effects of dual care?

The specific problems also result in specific negative effects. We will focus on four areas in the following.

The impact on customer relationships is negative when duplicate actions result from duplicate contacts. At the very least, this makes an unprofessional impression.

The administrative effort and therefore the costs are also doubled when duplicate identities are maintained. Or even higher, the more systems have the same content.

For data protection (GDPR), all systems must be recorded separately, and the data updated in the event of changes – promptly, of course.

Effects on authorizations (Entra ID) or personnel issues (HR system) are asynchronous. This can also lead to legal and security risks.

Centralized contact management – solution or outdated strategy?

The myth of centralized contact management in just one system is still widespread today – mostly in the CRM context. The wishful thinking that HR employees maintain IT systems does not usually materialize. It is just as unlikely that IT will want HR to control their authorizations. CRM systems for sales employees, on the other hand, generally contain neither authorization groups (IT) nor employee cost centers.

A centralized system for one use case makes sense – this applies in particular to CRM and customer management. If there are several systems for the same or similar purposes, consolidation always makes sense. There are various success stories here.

But how centralized can such a system be in an overarching context, i.e. from the perspective of the company as a whole?

An overarching solution is always desirable. However, as described in ‘Duplicate identities in multiple systems – who is responsible?’, the question of responsibility and the ability to compromise always arises if only one centralized system is in use…

…and this is where the centralized contact management approach regularly fails in practice.

Strategy for 2025: Decentralized sources, distributed management – is that possible?

The dispute over the true and central system can hardly be resolved. Why should it be? They all have their functions and reasons to exist.
You can do it without central contact management.

What if different sources coexist (Entra/M365, HR, CRM, AD via IDM-Portal, etc.) and transmit data to a central, very fast system? Each system can decide which data it sends.

This central system is called my-IAM RealIdentity and has been designed precisely for digital identity management. Digitalization here means managing identities across system boundaries. RealIdentity recognizes when an identity is created twice – and that’s basically ok!

Various mechanisms are used to sort and consolidate or merge different source systems. In the end, a suitable data set is available for everyone (for everyone who wants it).

What about the display, how do I use a my-IAM identity? The same applies here – as required. Because my-IAM RealIdentity provides the data for everyone:

• Existing global address books
• Your own my-IAM PeopleConnect front end as a web application
• Outlook
• Teams
• Mobile apps for Android and iOS
• All systems that can use REST API as a source, such as
• CRM and HR applications

Merging data from multiple systems is a good idea, but it already exists, right? Not quite. my-IAM RealIdentity takes a different approach. Seamless Microsoft integration allows the status of these M365 users to be displayed, for example. The speed of the data, the comprehensive search functions and the handling make all the difference. Everything is many times faster and more comprehensive than before thanks to container and cloud technology.

Write back? RealIdentity can also be used as a source for existing data pools. Even if they themselves are already the source? Even then. Selective write-back to supplement certain data is also possible.

my-IAM bridges the gap between different source directories, different maintenance applications and cross-company use cases.

As part of a digitalization strategy (e.g. Strategy 2025), more is possible than just avoiding duplicate contact maintenance.

Conclusion

Duplicates can be avoided. However, they can also be used specifically to provide additional information about an identity.

Avoiding duplicate contact maintenance does not necessarily have to be the goal. However, it should be avoided that the same data is maintained twice for the same person. And this does not require centralized contact management.

How this can be achieved is described in the Strategy 2025 section. Decentralized maintenance with multiple systems and a flexible and powerful identity provider, such as my-IAM RealIdentity.