[Proposal] Issues with automatic contact creation for incoming e-mails

ERPNext Selling/CRM
1

Hi everyone,
I’m in the process of setting up ERPNext for my company right now and ideally would want to use as many features as possible.

One of them is the email inbox, however, I have my issues with some of its functionality. To be more precise, I don’t like that ERPNext automatically creates contacts for new email addresses.

  1. The identification of the contact’s name doesn’t work well. Most of the time it ends up with setting “john.doe” as first name when the email address is “john.doe@example.com”

  2. While searching for existing data with the respective email address, it only checks the contact email child table. However, contacts are not the only type of references. An email could also belong to a lead, an opportunity, an address, user, etc. Because it checks only in contacts, a lot of duplicates get created if you already have the email address saved in one of the mentioned doctypes.

  3. This point is closely related to the previous one. The assumption that all emails are sent by contacts is not reasonable. If the email address is something like “info@example”, then this should most likely not be saved as a contact, because a contact has to be a person (with first name and last name).

Because of this, the automatic contact creation leads to spamming in the contacts list with trash data most of the time in my opinion.

My proposal to solve this problem would be to turn off the automatic creation of contacts and instead make some sort of periodic check if an email can get linked to an existing contact, address, lead, opportunity, …, so that the timeline links are still all there if you add e.g. a contact with that email address afterwards.

What do you think? I’d love to hear your opinion. Maybe there is also someone who benefits from the automatic contact creation.

If you like the idea, I could contribute with a pull request.

2

I looked into the code a little bit this afternoon. What I had not thought of is that the script that links the communication docs to the contacts is inside frappe, but a lot of possible linkable doctypes are from erpnext, so it’s not possible to hard code these.

However, I created a prototype script for the matching process that accepts a dictionary of doctype and docfield for finding the linkable docs. This way, the script can be dynamically loaded with the desired doctypes.

My idea would be to create a communication settings doctype with a child table which holds the doctypes and docfields that get looked up by the script. Thus, custom apps can also extend the functionality to new doctypes.
Furthermore, on the communication settings page could also be a checkbox for enabling or disabling automatic creation of contacts.

1 Like
3

Same observations and nice elaboration of problem agreed to improvement

1 Like
4

We are facing similar challenges at our company. Currently we have it set to create Leads for each incoming mail from an unknown address, but this also is not that helpful. As you mentioned, there are often other DocTypes where the email address already appears.

If you could publish your prototype code i would be very interested.

5

Hey @fzeidler,
it’s been a while ago since I created the prototype, so I don’t know if it still works, but I published the branch for you here:
https://github.com/P-Froggy/frappe/tree/refactor-communication-linking

The interesting commit ist here:
https://github.com/P-Froggy/frappe/commit/774fc32c14cc4ab0fb97b45bec184a9fb6e29926

It’s basically just a dictionary (the variable is named “references”) telling the function “get_docs_for_linking” which fields should be mapped. Instead of hard coding the fields which should be mapped in the variable, the dictionary could also be a child table in a new communication settings single doctype in order to let the user add new mappings.

I stopped working on it because someone else published a commit which added the option to disable the automatic creation of contacts from emails, but maybe we could get this working if it’s a good contribution to the community.

1 Like
6

Thanks @P-Froggy, that looks quite useful. I agree that getting the doctypes and fields from a child table on a communication settings single doctype would be great.

I’m quite new to ERPNext development, but I’m happy to help. From reading Contribution Guidelines · frappe/erpnext Wiki · GitHub It seems to me to get this accepted by frappe the next step would be to create a Proposal on Github with mock-ups, and request feedback from a maintainer. Maybe they can give some input on whether to create a new single doctype, or if these settings should go somewhere else.

Do you want to create the issue? Are there any parts I could help you with?

7

Hey @fzeidler, sorry for the late response. I had too much other stuff to do in the recent weeks.

I could try to finish the project and create a pull request, but currently it’s not on top of my priority list and it won’t be until October. If someone else is willing to help you earlier, feel free to use the code I posted above.

8

Thank you for the update. In this case I might fork your code and work on a pull request in a few months when I’ve gained more experience with the framework by building a custom app first.