I’m trying to figure out where are my Emails I received? I imported Emails into the “emails” table in suite but I can’t see them in the “Emails”-module. Do you guys know what I have to do with them when I imported them into the table?
When you say you “imported emails into the emails table”, are you talking about a database import? Or did you use the regular method of connecting an email account with SuiteCRM and then importing from the UI?
So it seems your Import isn’t complete for some reason.
I don’t know all the details of how Emails should be stored, but try to look in phpMyAdmin at how an Email created normally, from the UI, is stored in those tables, and perhaps in other related tables. You must be missing some ID, some relationship, to make sure that SuiteCRM sees the Emails where it should.
@neon - "1. It’s the latest version. " it’s not an acceptable answer… go to About and provide full version info - for both platforms so we have something to work with. Also provide server side info: php, webserver, hosting…etc …
From what I understand:
you have salesforce and suitecrm
you want to migrate e-mails from saleforce to new suitecrm instance?
you imported a dump of the e-mails table in salesforce into the e-mails table of suitecrm?
did you just import only the e-mails content ??
reason why you won’t be able to see the e-mails is that both systems are based on relational databases. if you are going to take a look into the inbound e-mails setting, each one has an ID in the DB. when an e-mail is received in that email account the id if the account is used as a relation to the e-mail record so to make this work and to see the e-mails you imported make sure that the inbound e-mail ID = inbound E-mail ID of the record imported.
Had the same issue with data migration from old suitecrm to new install suitecrm. To test if this is the case:
login to mysql
select your CRM database
select id from inbound_email;
this will provide you with the list of email accounts you have set as your inbound accounts.
select the id of the account you are using as your inbound account and run :
select * from emails where mailbox_id like "ID";
– replace ID with the actual email ID.
To fix this you could try a simple replacement of the ID in the inbound table with the ID of the inbound email you have on your salesforce install, or replace the mailbox_id of the e-mails in the emails table.
Let me know if this works. This solution worked on my migration when I couldn’t see the e-mail imported from a different instance of suitecrm not other CRM system so IDK if from salesforce is the same…shouldn’t be to far from this tho…
Ok. As you have the e-mails from another CRM system, things might get complicated, reason why some providers offer a migration solution. I DO NOT represent any vendor and HAVE NOT ever used any of their services so I can’t suggest any. Please look into a migration service as I don’t think you will be able to do this by yourself with the desired outcome. <<== This is my advice !
E-mails and e-mail information are stored under multiple database tables. For example:
This is how SuiteCRM stores e-mail and E-mail information (not the only tables). If you can figure out the logic behind the e-mails module and the relationships between the tables/columns then you might have a chance. You would need to compare the SalesForce database schema with the SuiteCRM DB schema (as it’s based on sugar then see this https://apidocs.sugarcrm.com/schema/6.5.24/ce/index.html) and the manually import the info in the correct columns. Theoretically it’s not that complicated, but due to relationships it can be tricky to see all info in the correct fields.
I don’t know, we don’t have this level of technical documentation… what I would do, if I was in your place, is to do stuff normally from the UI, and compare what you find in the database with the other lines generated from your import. You should be able to spot the difference between the ones that don’t work, and the ones that do.
You might need to look also into related tables.
Of course, there are other alternatives: using a higher-level function to import (Beans), or debugging through the code reading the emails, etc.