Navigation doesn't work after trashing/archiving an email

[yuri]

It won't be removed as it were there from early days.

"Modern standards" it's a moot point. And it feels harsh for me to read. I'd avoid referring features/approaches as modern or non-modern, and right or wrong. It's manipulative. We should not compare CRMs/ERPs with Inbox/Chat Apps. The latter are built around emails/messages. The former have different purposes. I could not find information about the paradigm shift into treating emails as tasks.

One may also say that treating Emails as Tasks is not the best way. It has drawbacks:

• A topic is often scattered across multiple emails.
• Email does not have Due Date, reminders, not visible on Calendar.
• A user gets an additional task-like entity instead of having only a Task entity.

In the case of using Threads, an Email becomes not a first-class too. The Thread is a first-class. The same as the Case is a first class for support teams, the Opportunity/Lead for sales teams.

As I mentioned before, instead of investing into becoming an advanced chat/mail app, we'd rather improve our current Stream feature. Improve what already is there. We are CRM first, and partially in the ERP zone. Using entities like Case, Lead and Opportunity is the way to go.

When creating a Task from an Email, it actually links them internally. There's one-to-many relationship between them. You can see all related Tasks from an Email and whether they are completed. It's also possible to add the Tasks field to the Email's list view layout and see whether a task is completed w/o opening the email.

Regarding Parent. Meeting/Call/Task/Email are secondary objects. Account/Contact/Lead/Opportunity/Case are primary. Email should not be a parent of something. It's how the system was designed. But you can easily customize it so that an Email will be a Parent of a created Task.

In Espo, an Email has Assigned User, Teams, optional Stream, it is customizable with custom fields, can be automated with scripting tool and Workflows. It's quite a lot for an Email entity.

[SoBeGuy]

OK, as usual, thank you for the detailed and thoughtful reply. I apologize for my use of "modern standards". You're right that it's not valid to compare a team collaboration app with a CRM. My frustration is that I'm trying to migrate our team away from Missive, which is a collaborative email app into Espo, in which email is only one of many components. The benefit of Missive is its speed and efficiency of handling emails. When an email comes in, it shows up in the team inbox. As soon as someone starts replying to it, all other team members can see that person typing the response in real time and they can simultaneously add comments to the stream. Email threads can also be snoozed until a future date, at which point they resurface in the inbox. This is what I meant about treating emails as tasks. They're not literally tasks, but they function like tasks in the sense that they automatically reappear in the inbox. In many cases, it's faster to simply snooze an email, rather than having to create a separate task. The email thread already contains all the information, so when it reappears, you know what needs to be done, without having to manually create a task based on the same information.

Nevertheless, it's good to know that tasks are linked to emails. Since it adds the link to the comments field, I assumed it wasn't linked internally. However, I'm wondering why you chose to add the link to the comments field, rather than linking it in the sidebar like any other relationship. Adding the link to the comments field can be problematic because the field is user-editable and someone could inadvertently remove or mess up the link. I also noticed that the email field doesn't appear in any of the layout options for tasks. I think it would be better to offer both options for linking emails. In my case, I would disable adding the link to the comments field and only add it to the sidebar.

Beyond this, it would be great if Espo supported a threaded email view, even if it's not integrated with the stream. And I'd love for websocket to support presence and typing indicators.