Hey all, I searched through but couldn’t find anything relevant.
Is there a way to merge two entities together (of the same type) so that their fields and relations all smoothly add up without conflict?
1 Like
Hi!
I’m afraid, no nice way to do that. But really curious to know about the use case you have 
I don’t know if this is similar enough, but my needs related to this are around imported/synced data:
That thread refers specifically to integrations, but imported data from e.g. CSV would likely often suffer from similar issues.
Well, I think CSV import improvement and specific action like “Convert”, but “Merge” will be two different solutions for two different cases (both of them are important for sure!)
Thanks for the link, will note it too 
1 Like
This now seems more like a feature request to me, and something I have a growing need for, as I referenced above.
I ran into this issue today. I’ve been a dumb human and created two records that, at the end of the day, are really the same thing. I want to make them the same thing. The problem is I can’t just delete one without moving over some of the fields and content, because they each have their own special flavor of filled-in fields.
I can copy and paste in a table view, but I have to go field by field and be careful not to overwrite data. Then I’ll have to manually merge a few columns where both records have partial data.
2 Likes
I have a (very common?) use case 
I have an agency and I’m setting up Fibery as a CRM for my clients. The contact records will be filled manually and via other systems/integrations.
- Manually: you get in touch via LinkedIn/Instagram DM and add a lead to the contact database. You don’t have an email address yet but you do fill in all kind of other fields (notes, lead status, lead channel etc.).
- Via integrations: when a Calendly (sales) call is booked, then we update or create the contact record. We do the same when an order comes in (and with a few other scenarios).
The problem is that:
- You often don’t have an email address in a early stage (for example when you have contact with a lead via DM)
- You always have an email address when a Calendly call or order comes it
- But people use different email addresses
- And we have several situations (in Holland) where people have the same first name and last name (but aren’t the same person)
So currently we check based on email address if a contact exists. We found a way with @Chr1sG to make a ‘possible duplicates’ view in the contact database.
- Contacts with the same First name + Last name
- But with a different email address
First we thought ‘merging’ was not needed. We just add a ‘second email address’ and delete the newest record.
But I just found out with a real life example that we still need it.
- Record A: (manually added) Firstname, Lastname, Leadstatus field, Notes, etc.
- Record B: (system added) Firstname, Lastname, Email address, Order (linked product + price), Project (automatically created when a new order comes in)
So now we want to keep record A since it is the original one. But record B contains a lot more than only an extra email address. Without a merging option our clients needs to do a lot to link the order and project to the right contact.
Possible solution (hopefully)
@Chr1sG can we make an automation button that we can press manually to merge two contacts? That would be a great solution without an official ‘merge option’.
1 Like
Hi @YvetteLans,
I’m sure we can figure something out, and hopefully other Fibery users will benefit from what we implement
Just want to check something: in your example, the two entities represent the same person, but they have differing pieces of information. In some cases, one entity is empty (which makes it obvious what to keep) but what should happen if the two entities contain information that contradicts:
| Firstname | Lastname | Leadstatus field | Notes | Email address | Order | Project | |
|---|---|---|---|---|---|---|---|
| A | John | Smith | Open | Is a solopreneur | |||
| B | Jane | Smith | j.smith@gmail.com | #1234 | OPD | ||
| Result | ? | Smith | Open | Is a solopreneur | j.smith@gmail.com | #1234 | OPD |
Hi @Chr1sG,
Thanks for the quick reply! For my own clients I think the chances are likely that they do need to take some action manually:
- First they need to make sure that it is indeed the same person. They can check that based on a lot of variables.
- When they think record A and B is the same person (because John decided he wants to be a woman per now on ); then they will continu to step 2.
- When they think John and Jane are seperate persons, then it would be helpful if they can check an ‘ignore’ checkbox or so (and then we can decide to not show the entities with ‘ignore’ in the ‘Possible duplicates’ view)
- Then they need to decide which record they want to keep. I think in every situation I can think of, that that should be the oldest record (so let’s asume that’s A in your example).
- Then you want to add the information of record B into A and delete record B.
What I would suggest is that only if a field is filled, the data can be overwritten.
So when we merge information of record B in record A in your example, then the lead status will still be open (we won’t overwrite it since the field is empty in record B)
There are two situations that the user should be aware of (we will make a help guide for this)
- If record A contains j.smith@gmail.com and record B contains j.smith@hotmail.com (so different email address), we want the email address of record B to be placed in the ‘secondary email address field’ or record A (either manually or we can let the system do that if that’s not to complex).
- If record A contains a postal address (13th Street, New York) and record B also contains an address (let’s say 7835 Ridgeview Av, Brooklyn) then after the ‘merge’ the address of record A will be overwritten by the address of record B.
That should not be a problem. Because we normally only get the postal address when a new order comes in. And when a new order comes in we can assume that that postal address is indeed the most recent postal address.
And finally: the above is only applicable for fields (since we can only have one value in a field). The orders and project are entities in seperate database. So there we can add entities instead of overwrite them.
I think this will cover all real life situations in CRM scenario
TLDR;
- User decides which record should remain after merge
- User accepts that after the merge the information in some information can be overwritten
- User will be very happy if we can somehow don’t overwrite the email address while merging but add the email address in the secondary email address field. Because most clients will have multiple email addresses (but not multiple postal addresses)
- But user will not cry if he/she needs to add that email address manually in a field if that’s not possible
Edit: pro tip for if somebody wants to build the same solution… If system finds out that we have a possible duplication, we will set a checkbox so that the contacts can show up in a view.
We will also create a task in user’s daily task list with something like “We currently noticed that there maybe is a duplicate contact within your contact database. Please check the ‘Possible duplication’ list and follow the instructions.”
Just to make it extra dummy proof 
l
Here’s a template for merging contacts. It has a button, which allows the user to choose which ‘destination’ Contact an entity should be merged to.
It has a couple of formulas that determine how the various fields should be updated:
- the email (primary) in the destination is kept, and if an email exists in the ‘source’ it gets written to the secondary email field
- the state is updated with the value in the source
- notes in rich text field are appended
- orders in the source are added to the existing orders in the destination
These rules may not be exactly what you need, but hopefully give you an idea of the possibilities.
1 Like
Thank you so much! Looks awesome! Will need to dig a bit deeper into all the formulas.
Only problem I have right now:
- We only want to merge if it’s the same person
- When it’s the same person, we have exactly the same name
- In my test I’ve choosen the wrong entity while merging (you can’t decided where to merge to because both contacts with exactly the same name are shown)
Is there maybe a way that we have more information about the contact so we can decide where to merge to? Maybe/hopefully we can show the creation date of the entity somehow in the dropdown? 
Thanks again!
Yeah, I realised that after I published the template 
It’s actually a weird side-effect of the fact that an automation can theoretically run on a batch of entities
(but this shouldn’t happen in this specific case - in fact you mustn’t try and merge multiple entities into one destination at the same time).
Anyway, I’ve two possible suggestions:
-
don’t use a button(!) and just link items from a view. You won’t get offered the entity itself:
-
tweak the name formula so that entities can always be distinguished:
Hi Chris,
Thanks again! Difficult choice 
I’m thinking about both options!
- because I really like the idea to link the contact in the ‘Merge to’ field
- but (due to integrations) I can also imagine we have 3 contacts; then it would be great to see to which contact you want to merge
- and it can be helpful that you visually know that you have indeed two people with the same name in your database when they aren’t the same person
So that would do the trick I guess 
Well, here’s another thing you could try: you can use a formula for the Name field that only adds the numerical identifier if there is a duplicate.
As I recall, you’re using an auto self relation to find matching items. You could maybe use something like this:
Voornaam + " " + Achternaam + If([Niet verwijderen - Check dubbele contacten - 1].Count() > 1," (" + [Public Id] + ")","")
A feature to merging entities (not requiring automations) would be useful for end users, and my team does doing merging manually on a daily basis because of the following use case:
I have ‘hub’ entities which function like index notes in a shared zettelkasten, and they create collections of pages that often have the same function as a book with chapters, or a growing evergreen report, or a collection of meeting notes.
Current workaround: feed view
- Manually create a feed view of the pages filtered by the hub relation.
- Use chrome rightclick to print as pdf.
Because this requires a lot of manual configuration of the feed view filter for a specific relation, we often end up copy pasting content into a new entity. Both solutions are not ideal.
1 Like
Hi,
This is really interesting. I am trying to do something like this and struggling. Any chance that template could be reshared?
1 Like