First, welcome to our forum.
Second, you need to define (for yourself) what you really mean by "storing e-mails in Access." You use Outlook to store e-mails and attachments to those e-mails. That's one of its intended features. You might, however, choose to store information about an e-mail in an Access table somewhere and leave information about that e-mail that would help you find it again.
The biggest stumbling block you will find here is that you have a limited storage space in Access that isn't commensurate with the potential storage space of Outlook. I.e. Outlook can easily expand to be bigger in storage space than Access. It is FAR easier to add a second, third, or tenth Outlook .PST file than it is to integrate multiple Access .MDB or .ACCDB files.
Another issue is that you would be combining e-mails from a lot of people into a single Access data file. All this does is drastically accelerate the bloat factor. It would take you no time to fill up your storage area. When you are storing extraneous data from multiple sources, you would be surprised as to how quickly you chew up 2 Gb (the limit of a single Access database file).
What you can try to do is open Outlook from some VBA code and browse around in an "InBox" to look for mails of interest. Or perhaps build a list and have a user select the mails of interest.
The way that I manipulate e-mail doesn't involve input from an e-mail so all I can do is give you some ideas and guidelines. However, I generate lots of outbound e-mails so I'm not totally unfamiliar with using Outlook from Access.
To attack this problem, you need to do some reading and research. In essence, you will want to learn how to open an Outlook Application, after which you will be using the Outlook App Object as the anchor for a bunch of object-defined method operations. You will have to look in two main places.
The first place is Access Help on the subject of Application Objects and the care and feeding of same. They will give you the basics of object twiddling but then it will be up to you. The sample Northwind database might be helpful for general examples of this topic.
The second place is in Outlook Help on its subject of VBA programming, because it is in that help file that you will see the internals of Outlook's common object model (COM) - the list of Outlook collections, objects, methods, and properties that are available to you. You will find the oddball nomenclature that Outlook uses. For example, any other place might call something that you open for examination a "Collection" or a "Window" or a "Recordset" (depending on what it is.) But Outlook often calls such things "Inspectors." I guess because you can inspect things in it, but why it isn't a collection, I'll never understand.
It probably wouldn't hurt to visit your favorite local book-seller chain store to see what they have in the programming section on VBA either.
One last bit of advice. AFTER you have done your reading to see what tools are in your potential toolkit, carefully consider what you really wanted to keep - and how you want to keep it. Redundancy is going to be costly in a potentially high-volume database with a limited storage bin. If you keep the whole e-mail message plus its attachments AND keep the orders associated with each mail, you are double-dipping.
If I were to do this, I would find a way to keep the sender, date, subject, and perhaps the name of the person who actually processed this e-mail. Maybe a couple of check-boxes to indicate whether an order was part of the deal. Maybe a check box to say "Phone" vs. "E-mail" - since you mentioned in passing that phone contacts would also be important.
This also has procedural implications about keeping the original order e-mail from multiple sources as a means of business-record keeping, since you don't want to lose track of revenue-generating communications. I'd say "paper trails" but who uses paper these days?
In closing, what you want is certainly possible if you are careful UP FRONT in the process by assuring you know EXACTLY what you want to keep - and more important, what you DON'T want to keep. I say this because my mental "bloat alarm" goes off the moment I look at this problem. This beast CAN be tamed - with careful planning. Good luck.
