I understand that the individual solution can be built to read inbound email.  But what I am suggesting is to make this an official out of the box feature of APEX.  Thanks

While I would LOVE if this were possible, it is far more difficult you might expect, especially as every email platform's output is different.

I've been working on exactly this for a system I'm building and just between the Windows and Mac versions of Outlook email client, I'm having to treat parsing the HTML bodies completely differently. I'm lucky that I don't have to worry about random email clients to make this even more convoluted. 

God help you if you have to worry about attachments to an email. that gets even more dicey.

@doug.gault I agree that this is not an easy challenge and that may be the reason why we don't have a general incoming email processing feature.  But what I am thinking is not related to any email client tool.  I am just thinking about the features are on the server side.  I am no expert in Email area.  So this may sound silly.  

What I am thinking is the following:

1. Provide a server component that can talk to the Email server tool such as Office 365 via their publish APIs.
2. Then allow the application perhaps as a Shared Component to define the “Mail Box To Watch” email address and setup the proper credentials as part of this “definition”.  
3. Then just poke the email server for incoming messages for the specific “Mail Box To Watch” email address.
4. Parse out the messages via the published APIs on the Email server side and store the data in a structural Database APEX tables where it can then expose the data to the Application itself.  
5. There may be a separate APEX meta data table that stores the attachment.  The App may also specify the retention of these email data so that it doesn't clog up the database size.
6. Then provide APEX PLSQL/Javascripts API to read the email meta data tables and allow the APEX app to retrieve data out of the message to process the incoming emails.

When it comes to execution, APEX can first send out email using the current feature sets except that it can allow the user to add “buttons" to the email message such as Approve, Reject.  Then when the user clicks on the button, it simply generates a reply message with the proper tracking ID such as a Notification Id of some sort so that the APEX app can parse it and retrieve the data properly and track against the same Notification Id when it first sends the data.  This approach is what the EBS Workflow Email mailer uses.

I know that this is not an easy task.  But as a premier low-code platform, this is one area where there is not a clear solution to it and every one will have to build their own Email inbound handling solution.  So I am just suggesting that if the APEX team would consider this.  Thanks for your input Doug on this.

BTW, I think that I do have one of your books that you wrote…  Thanks for sharing your knowledge in this good product.

@jlam  - I'm actually in the process of doing exactly what you described in your steps. 

I think that Step 4 is where it all get really hard.

When you pull the email in from the mailbox, not all email messages are going to look the same or have the same structure. 

Part of this is going to be based on the Sending email client -Outlook, Apple Mail, Web mail  (such as google, yahoo, hotmail, aol, etc.) and so on 

Another part of this is the actual email server you're connecting to. They all treat and process incoming emails differently. 

In our case we're using MS-365 as our mail server and can limit our expectations of the originating mail clients to Outlook (from either MAC, WINDOWS, iPHONE or Android). Even so, the incoming messages are very different from each platform. 

Because of the non-homogenous nature of the email body structures (Even though we formulate the body for the end user), we're having to use MS PowerAutomate to pre-process the incoming email messages and homogenize them,, place the processed message in a Sharepoint folder and then peel them off 1-by-1 and parse through them with REGEX to get the relevant information. 

Now increase this complexity by having to potentially support innumerable Mail Servers and it becomes almost an impossible feat. 

I completely understand why you want it.. But having gone down the path of writing code to do this, I can also see why this would be a monumental task to integrate into the APEX core.

@doug.gault Thanks for the insight again.   This is helpful to understand the challenges.  You should write a book about this topic…:)  Thanks

@jlam 🤣🤔👎

Thanks but I think my book writing days are behind me. It was a really fun an useful exercise, but very time consuming and very definitely not a money making venture!

Duplicate of rejected request FR-1797