"Unexpected values found in emails" when upgrading to 8.0

According to sugarcrm, this is on purpose (https://support.sugarcrm.com/Knowledge_Base/Installation_Upgrade/What_to_Expect_When_Upgrading_to_8.0/ )

7.9: Email records may have a status of Read, Unread, Sent, etc.

8.0: Email records have a status of Draft or Archived."

That is a silly step back...

The global Customer Support departments at my company are also very dissatisfied with the two email module changes within the v. 8.0.1upgrade:

1. The removal of being able to "send as" a group user

2. The new status of Draft and Archived

We had to cancel and postpone our go live with 8.0.1 for the first issue and first pay our implementation partner 2 days of programming to create a workaround. We definitely do not want Support emails being sent from personal email accounts.

The second issue is still und investigation to bring it back to the old status values. Unbelievable, an Email program that is not able to show read and unread. It is the basic idea of emails.

Also the field object for the text body on the email is not resizable, like other larger fields for descriptions and very small with a second scrollbar at the side. Looking at a larger email text, this is very frustrating. So we had to customize ($$) that one as well.

Is Sugar still doing any usability tests with customers? Would like to get these issues solved by Sugar asap, or the product manager for the Email module should pay for all the workarounds out of his own pocket.

Johan,

First and foremost, thank you for your feedback.  As the SVP for Product Management, I am ultimately responsible for this decision and I hear and understand your concern with the changes.

Let me explain the intent behind the new email module.  The redesign was the first step in a shift in Sugar’s view of the role of email in CRM. Sugar is not intended as an email client. W e’re not trying to build a replacement for Outlook or Gmail. Our view is that email is an important source of information necessary to nurturing your customer relationships, and Sugar users should be able to find, interact with and send emails in any context, whether it’s from an account, case, opportunity or quote. This new perspective is evident when you consider improvements like the ability to preview emails from a subpanel or open and send draft emails without leaving the record you’re working on.

That said, we recognize that sending email from a shared account and viewing the ‘read/unread’ status are important, especially in support use cases.  We’re investigating the best ways to address those in the future. The size of the email body field in record view is another item that we’re hoping to improve in a future release.  I'd be happy to schedule a call with you to discuss your particular usages of email and to investigate possible mitigations.  This would give us an opportunity to ensure that as we continue to evolve the email offering that we do so with your use cases in mind.

Johan,

First and foremost, thank you for your feedback.  As the SVP for Product Management, I am ultimately responsible for this decision and I hear and understand your concern with the changes.

Let me explain the intent behind the new email module.  The redesign was the first step in a shift in Sugar’s view of the role of email in CRM. Sugar is not intended as an email client. W e’re not trying to build a replacement for Outlook or Gmail. Our view is that email is an important source of information necessary to nurturing your customer relationships, and Sugar users should be able to find, interact with and send emails in any context, whether it’s from an account, case, opportunity or quote. This new perspective is evident when you consider improvements like the ability to preview emails from a subpanel or open and send draft emails without leaving the record you’re working on.

That said, we recognize that sending email from a shared account and viewing the ‘read/unread’ status are important, especially in support use cases.  We’re investigating the best ways to address those in the future. The size of the email body field in record view is another item that we’re hoping to improve in a future release.  I'd be happy to schedule a call with you to discuss your particular usages of email and to investigate possible mitigations.  This would give us an opportunity to ensure that as we continue to evolve the email offering that we do so with your use cases in mind.

Zac,

Sorry to pile on here but Sugar's "shifting views on email" is unfortunately only considering the perspective of non-support users.  Of course no one wants to replace the native email functionality for the sales users, the finance users, etc.. but case management is different.  When you try to operate a support system based on a generic "single point of contact" like support@domain.com the email communication workflow needs to be 100% web-based and contained within Sugar.  No one wants to operate a support system from Outlook - Anyone who has done it knows it is madness.  There is solid value in keeping the support case information housed in one common CRM platform . 

I recognize that while SugarCRM's support@ email address technically integrates into your instance of Sugar, you have customized it to avoid all of the default functionality that you deliver with the product.  I REALLY wish you ate your own dogfood here, as the case management functionality is probably the weakest part about SugarCRM.  I think that if you were forced to actually use it, it would be much more developed and useable without a bunch of workarounds. 

On a positive note, I am happy to see the updated look and feel to the email module.  I would love to see the WYSIWYG editor support pasting images into an email (as this is often needed in support instances and the TinyMCE supports the functionality.)  Would also like to see the complete set of legacy email workflows implemented into the process author modules.  I sure hope these don't get dropped along with the new vision.  

Happy to discuss.

Dave

Hi Dave,

Thanks for the reply.  I'm happy to report that we do use Sugar internally to support our customers so we do have first hand experience with some of the challenges you identify.  I hope that you'll be happy to know that we are actively developing some new capabilities with regards to support.  I'd be happy to discuss your use case so that we can ensure we're capturing your needs as well.

Any updates? It's now July 2019 and 9.0.1 is still not updating the Email Status field or displaying it by default in the Email list view.