# Merging synced data to existing types and avoiding "type proliferation"?

**URL:** <https://community.fibery.io/t/merging-synced-data-to-existing-types-and-avoiding-type-proliferation/1946>\
**Category:** Ideas & Features\
**Tags:** integration\
**Created:** [August 27, 2021, 1:06am UTC](https://community.fibery.io/t/merging-synced-data-to-existing-types-and-avoiding-type-proliferation/1946 "2021-08-27T01:06:30Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [February 18, 2022, 1:55am UTC](https://community.fibery.io/t/merging-synced-data-to-existing-types-and-avoiding-type-proliferation/1946/6 "2022-02-18T01:55:54Z")

</div>

I’m not sure I actually defined the problem that well (or clearly) here, originally. Basically as Fibery has an increasing number of (great!) integrations, you end up with numerous systems which might have the concept of a “Contact” or “Person”, e.g. Hubspot, Fibery itself, Intercom, etc. It sucks to have all of them have totally different contact Types when a lot of the basic information is shared. Obviously there are potential issues with sync and what integration overrides the others (or do they just keep overwriting each other? 😄), but the _real_ desire here is to have a “single source of truth”, which might ultimately require [Bi-directional integrations/sync](https://community.fibery.io/t/bi-directional-integrations-sync/1691). In any case I just wanted to clarify this since I have an increasing need for this kind of capability, as I am raising elsewhere in my posts today.

---

_[View the full topic](https://community.fibery.io/t/merging-synced-data-to-existing-types-and-avoiding-type-proliferation/1946)._