I actually try and avoid pulling in emails and reading employee's email boxes into CRMs. There's all kinds of red tape that comes along with dipping your system into personal email accounts (even if they aren't technically personal).
What's more common is to have a "catch-all" email address, like email@example.com, that is read into a notifications table in the CRM.
All in all, most CRMs are dependent on users manually creating relevant records for their communications to record it. Yes, some of it can be automated by having the ability to email directly from filemaker and create a record en-route, but that is less feasible for calls (although there are PBX and other phone integrations that exist).
Client training is paramount in using the system. And as a developer, gathering the requirements from your requirement for what's expected is important before taking on a project.
I agree with Mike. I advocate having a generic email box e.g firstname.lastname@example.org and pull that tyhrough. I have used a product from Dacons to successfully do that. They have given excellent support considering they are in NZ and I'm in the UK.
The one thing that I am still trying to resolve in the back of my mind is maximising the chance of emails being successfully delivered.
Our base solution (xBase) can be used as a full email client, and uses 360Works' Email plugin.
mikebeargie, I agree that there are challenges when getting into users' "personal" emails. We counsel our clients that if that's an issue, they can set up a separate email (overall or per user) for FM use, and let users forward relevant emails to the FM account(s).
Where primary emails are used, though, it's a helpful reminder to employees that a work email isn't "personal" or "private". Maybe employees who knew that an emails they traded with "Helga's House of Pain" could end up being viewed by the whole company wouldn't misuse their company emails. ;-)
It may not be obvious at first, but the real benefit of integrating email into FM has turned out not to be the emailing itself, which other programs do just fine. The real power is when you can link that email to various elements in the database, so that for instance when you view a customer record, you can see a history of their interactions with anyone in the company
Another benefit has turned out to be a side effect of having all the emails come into a single file. If you send an email to me, and cc a co-worker, we receive the email for whichever account checks first, and create a record. When the second email account encounters the same email, it adds that user as an assignee to the existing email, rather than creating a new record. This means that if my co-worker takes care of the email (replies, creates a task, whatever) then when I get to the email I can see that, and I don't have to go ask him if he got it, what he did with it, etc., nor do I risk both of us tripping over each other.
Working with the plugin (either 360Works', which I highly recommend, or others) turns out to be pretty straightforward. Working out the logic for things like combining emails (as described above), automatically linking records based on email address, etc., threading emails, and figuring out what attributes or foreign keys should propagate to new emails in the thread, all turn out to be pretty challenging. Very rewarding in the end, though IMHO.
We save our emails as just one type of "Activity" in the activities table, and other types include calls, voice messages, text messages, faxes, letters, meetings and more. We also leverage the email functionality to manage texts (if we know the carrier), faxes (via efax and the like), and voicemails (with VOIP service that emails voice messages).
(Incidentally, we originally included "tasks" as an activity type, but found that unlike those mentioned, those items had too many unique attributes, such as a due date, or not appearing on a fixed place on the calendar. We've now broken those out into a separate Objectives table... which you can link M:M with Activities.)
Coincidentally, we just yesterday decided that this would be the topic of the next meeting of Tampa FMPug. (http://www.meetup.com/Tampa-Bay-FileMaker-Pro-User-Group-FMPUG/events/226242457/). We don't have the gotowebinar details set up yet, but should shortly if you'd like to attend virtually and learn more about what we do with email in FM.
Not to necro the thread, but I thought I'd add that with many email services, you can use a group account with plus-sign tag to keep messages associated with different purposes.
For example, if you have FileMaker pro check an email account for "email@example.com", you could address email to something like "firstname.lastname@example.org"; it would arrive in the sales@ mailbox, and then FM could extract the "xyzzy" part to identify the thread.
There are different approaches to generating the tag. I wouldn't use a raw record ID, for example, or something terribly long. Certainly nothing you'd want to keep secret. Perhaps a simple hash of a thread UUID, or something similar.
But let's say your FM CRM sends an email to a customer. It could generate a random tag like "af391lkdn" and save it with the record of the outgoing message, then send it with a reply-to address of "email@example.com". When the customer replies to that address, it goes to the "firstname.lastname@example.org" email account, and FM retrieves it from there and stores it as a record. When it saves the record, it extracts the "af391lkdn" from the "To" field and that relates it back to the original outbound message. Now you can use that relationship to form a thread.