Inbound Email Workflow

Hi Alexander Fechner ,

Sugar does have some beneficial features in terms of handling inbound email via Cases. If you're not already using Cases for another purpose, then I think this is the most natural fit as long as your users are working from a common inbox. The case inbound flow will automatically link emails to contacts and their respective accounts on receipt and you can use SugarBPM to manage things like case priority and follow up dates. When replies on existing cases are received through that same email address, they are automatically archived to that case rather than spawning a new work item. 

If your users are conducting communications with customers with their personal email, then I think you should reconsider what is the best workflow because that would mean having to connect each users email to Sugar. While it's technically feasible, most users (and admins) would not want this level of email coming into the CRM.

Chris

My two cents: Use Cases and make your users use Sugar as the email client to respond to those cases

Emails are a complicated beast and the relationships between Emails and other modules are, to say the least, difficult to manage.

If you have navigated the back end tables of Sugar you will know that there are two primary ways that an Email can be related to a customer:

Email <-> Email Address (participants) <-> Contact/Lead/Account that has that email address related to it, for example:

emails<->emails_email_addr_rel<->email_addresses<->email_addr_bean_rel<->contacts

There are also direct relationships:

Emails<->Contact/Account/Lead/Case/Quote/Opportunity/.... for example:

emails<->emails_beans<->contacts 

The latter, to me, is supposed to describe the context of the email. 
If you send an email from the Cases module it's related to the Case.
If you send an email from the Contact it's related to the Contact... etc.

If you add a relationship between Emails and Task, all you are doing is adding yet another Bean Module to the list of allowable ones in the emails_beans table, adding to the chaos.

Reporting on Emails is often misunderstood as the emails_beans relationship is often mistaken to be the one to give you all the emails for a given Contacts, which is not the case in my experience.

Our Sales team does not use Cases or the Sugar email client and we've had many challenges over the years in logging their emails.
We established an inbound email address that they Bcc on the emails that they compose but it's one-sided. So we then had to code some ways for them to log emails that were received by forwarding the email but they rely on a bunch of code that reads the body of the email to try and find the original sender and swap the to/from.... a real pain to maintain and don't recommend it. And even after that we have no way of knowing if someone contacted a salesperson directly and got no response.

One lesson I learned the hard way... just because you can, doesn't mean you should.
Keep your Sugar instance as simple and un-customized as you possibly can.

FrancescaS

Chris Raffle said:

If you're not already using Cases for another purpose

Even if you are using Cases for another purpose you can set multiple Inbound Email records and control their assignment via Team. We use the primary Team to set a custom "department_c" field on the Case. That then informs some of the schedulers for notifications, escalation logic, etc...