top of page

The Microsoft Access Team's Position on New Outlook

Updated: Nov 7, 2023


In a recent article, I described that Microsoft is working on a New Outlook to replace all current Outlook variants, including the classic Outlook for Windows in a few years. New Outlook does no longer support COM and thus all VBA solutions that automate Outlook would no longer work.


I asked the Microsoft Access team to present their current position on New Outlook in their session at my German Access developers conference AEK25 on Oct 14+15, and they delivered.


Update (Nov 3): You can now watch the recording on my Youtube channel. Here is a picture from the recording showing their slide on the topic, as well as four members of the Access team. Software engineer Shane Groff and technical lead Dale Rector spoke on the topic.

The Microsoft Access team's slide on New Outlook at AEK25

The most important is in the last bullet point. The Access team assumes that the classic Outlook Windows client will be included in the next perpetual Office (LTSC, presumably 2024) and therefore will be supported at least until 2029 due to the usual support period of 5 years. This is not yet official, and the Office and Outlook departments will not give more specifics until next year. But still, this is a strong hint that the Windows client will not go away soon.


Another statement from the Access team was that if New Outlook really does replace the Windows client, they expect the Outlook team to provide a solution to the automation issue, which after all affects not only Access, but also Excel, Word and others. It was emphasized (see bullet point 4 on the slide) that - thanks to our noisemaking ;-) - there are ongoing discussions with the Outlook team about the issue. So, the responsible team has been clearly informed that there is a problem with a few million applications.


It was also said that should this "general" automation solution not come, the Access team would provide a solution specifically for Access, because they are aware of the importance of the matter for Access users and developers and the product. To put it differently:


Plan A, B or C?

In the discussion with the Access team, I mentioned that I had presented 3 possible plans for solving the problem in my previous conference session:


A) New Outlook fails to replace classic Windows Outlook, for whatever reason. Definitely the best solution for us Access and VBA people.


B) Windows Outlook is replaced and Microsoft delivers a satisfactory new automation solution. Be it an overall solution for all affected or the Access team specifically for Access.


C) Microsoft does not deliver anything usable for us. We as customers and developers have to create workarounds and solutions ourselves. That would be the worst option.


The Access team responded that they are strongly committed to plan A or B and certainly want to spare us C, not only out of customer orientation, but also because Access-internal methods for working with Outlook are based on COM.


Shane Groff said he could only stress that as much as they constantly stress that neither VBA is dead, nor that Access is dead, knowing that they can't stop the eternal rumors with it. There are always people with more insight than the manufacturer.


Summary message to all Access developers:

1,731 views10 comments

Recent Posts

See All

10 Comments


Fernando
Fernando
Feb 08

You mean "DON'T PANIC..... err.. YET!"

Like

Conan McGregor
Conan McGregor
Feb 06

Thank you for your work already done on this; I found your article while searching for solutions. I'm already having issues with this new Outlook. I have client's for whom I write macros to help with automating tasks, particularly in Excel, and they have many employees who are now using the new Outlook, especially when they're new employees on new computers. When the Outlook object is called, they have to go through the setup of the 2016 Outlook if it's not already set up. This isn't a catastrophic issue, but it kills the functionality in that instance and requires them to re-do their work and re-run the macros, sometimes requiring me to get involved while they're in the field, which…

Like

Paulie M
Paulie M
Oct 29, 2023

I also like to use graph or Power Automate to send emails (and lots of other stuff). Its a great way to send attachments etc if you encode attachments as base64.

Like

Gontran Harvey
Gontran Harvey
Oct 29, 2023

The other day I tryed the Azure API (ms graph) to send an email from my Access database. It works pretty great. I was able to send emails. I my case, I only use Outlook COM for sending emails, but when you read the Ms graph docs, you see that you can do about anything there. The only thing I need to test is how to create an email an opening it before sending it. I think I need to create a draf email, get the ID and open it in the browser (never try it for now). To do that is not user friendly if you never work with REST API, but at leat we know that there's a…

Like
Alan Bourke
Alan Bourke
Mar 04
Replying to

That's all good. - but with the COM-enabled Outlook client that we currently have we can just deploy software to a customer's site and as long as Outlook is installed on a PC, that software can leverage it to send email. To use the Graph API you need:

  • To check that the appropriate Azure AD licence is present

  • Set up the app registration

  • Set up API permissions

  • Whatever esle


All that is per-tenant so needs to be repeated by someone who knows what they're doing for every new customer using your software. But great for Microsoft as it's more Azure lock in.

Like

Richard Rost
Richard Rost
Oct 28, 2023

Yeah, but people love to panic.

Like
Karl Donaubauer
Karl Donaubauer
Oct 28, 2023
Replying to

Did you click at the "Don't panic!" link? Basil reminds me a lot of the typical Access/VBA deathtalker.

Like
bottom of page