# 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:** 3

<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:** [August 27, 2021, 6:43am UTC](https://community.fibery.io/t/merging-synced-data-to-existing-types-and-avoiding-type-proliferation/1946/3 "2021-08-27T06:43:45Z")

</div>

> [@Chr1sG](#):
>
> Can’t answer the first question, but I’m pretty sure that the only ‘fix’ at the moment is to define auto-relations that match on e.g. email address. It woyld allow you to see that there is related data in other apps, but is far from ideal, as you say.

Yes, that’s exactly what I’ve been doing. It’s helpful, but not _that_ helpful. 😄 It is unfortunately a far cry from the kind of “pulling it all together” that I’d like, and that I think Fibery has some promise to allow.

> [@Chr1sG](#):
>
> It sounds like you’re after a solution where, e.g. a contact present in multiple apps exists as only one entity, shared between the places where it’s used.

Well, more or less, yes, sort of, mostly. 😄 Any fields that had the same/common data would be shared, yes. E.g. Name, Email, etc. If necessary you might have to do a little jiggery pokery to make e.g. a system that uses a single “name” field compatible with one that uses first/last names (separate fields). And you might need to set one source as “canonical”, where the rest can’t write to it and only use it for matching, or just don’t write to it at all. But really the point is a _field-level_ data sync, I think…

> [@Chr1sG](#):
>
> Fwiw, I think with the current permissions model, it might be challenging. For example, if someone has permissions for the Airtable sync app but not for the Discourse sync app, where does the shared contact ‘live’ and what permissions should be applied?

Mm, that’s a good point and, to my surprise, raises the already-rejected idea of field-level permissions, e.g. [Customize Fields via Rules](https://community.fibery.io/t/customize-fields-via-rules/1523). Hmm.

So I don’t know. But the _promise_ of it seems, to me, to make the challenges of it worth thinking seriously about, and potentially solving. If Fibery wants to truly become the unifier of data, and thus the central “sense maker”, the place where all data comes to become “sensible” and derive insight from (as seems to be Fibery’s overall ambition), then I think this will have to be a part of it to truly achieve that.

---

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