If you’ve worked with SPA, iRPA or Outlook SDK in the past, sending an e-mail with SPA or iRPA should be easy! Simply add Outlook SDK to your project, create a new automation, open an Outlook instance and you can send your e-mail directly from your automation.

All of this is easy and straightforward… until you’re asked to send an e-mail from a shared mailbox. Not your own mailbox or the standard mailbox you have on your device; no, a shared mailbox without the same permissions as you’d have on a standard mailbox.

Below, Jana De Klerk and I share some tips on how to handle a shared mailbox and the steps we took to get our automation running on a virtual machine with a shared mailbox. We both encountered problems and had to work together to find a solution!

Adding the mailbox as a subaccount

The first hurdle we encountered was the fact that the mailbox was pushed into the Outlook account as a shared mailbox. Our automation had to read the e-mails and move them to a “Processed” or “Error” subfolder before sending them. Moving an e-mail was the first indication that a pushed shared mailbox was going to give us some trouble.

The solution was to ask the IT administrator to add the mailbox as a subaccount instead of pushing it. This allowed us to move e-mails from the Inbox folder to one of the subfolders.

Sending e-mails from a shared mailbox

Sending e-mails from a shared mailbox was our second challenge. Our automation ran just fine when using the main Outlook account. Reading e-mails from the shared mailbox and moving e-mails was no longer an issue, yet sending an e-mail was harder than we thought. We faced several different issues, which were hard to make sense of with the technical traces that were available. Looking back, the corrupted Outlook profiles should have tipped us off…

(Note: the following issues did not necessarily happen in chronological order.)

Issue #1

Sometimes the automation did not crash. This suggested that the e-mails were successfully sent, but somehow went missing. There was now incoming e-mail and couldn’t find any of our sent e-mails in the Outbox folder, the Sent folder or the Drafts folder. Restarting Outlook a few times made us realise that the e-mails were stuck in the Outbox folder of the other account (not the one who sent it).

Issue #1: mails end up in the wrong outbox folder

Trying to manually send these e-mails was not possible, as an e-mail can’t be sent if the sender does not match the Outbox folder of the sending account. Does that make sense?!

Issue #2

When we attempted to restart Outlook after the automation ran, we did not receive an incoming e-mail. We wanted to see whether the e-mail was sent or stuck in the Outbox folder. When we tried to open Outlook, we encountered the following error:

Issue #2: Outlook application error

We looked up error code 0xc0000142 and found three possible causes:

1. A virus in the Outlook application or Windows system
2. A corrupted registry
3. An error while updating Windows

In our case, we knew with certainty that these were not the cause. Microsoft also gave us possible solutions, but none of them worked.

When we attempted to restart Outlook, the next problem appeared:

Issue #2: Cannot open Outlook

On our third restart attempt, the Outlook application finally opened and something immediately caught our eye: a lot of RSS folders had been created. Below is a screenshot of this spam. (Note: this is what happens when folders are not immediately deleted.).

Issue #2: spammed by RSS folders

Issue #3

Outlook crashed when attempting to send an e-mail. When executing the automation, a notification appeared in the taskbar.

Issue #3: Outlook is busy

It was not possible to open the Outlook application. A few minutes later, we could open it again.

Meanwhile, the automation crashed with the error “Failed to send e-mail. Error: Failed to create email. Error: DispInvoke: CreateItem The operation failed.”

Issue #3: Automation error – failed to create mail

Issue #4

Another crash happened and the error description didn’t give us much to go on: “Send exception occurred.”

Issue #4: Automation error – send exception

When we opened Outlook, we saw the following error: “Outlook data file cannot be accessed.”

Issue #4: Outlook data file cannot be accessed

Solution

As we are automation experts and not Outlook experts, we contacted our IT helpdesk. Unfortunately they had no idea why it failed or why our e-mails wouldn’t send. It ran just fine on another virtual machine, which made us wonder whether our automation was the problem.

It turns out that the solution consists of two parts. On one hand some settings had to be set on default in the Outlook application and on the other hand a few adjustments had to be made to the automation itself.

Outlook

We went looking for answers. We made comparisons of other Outlook account settings, read blogs and scoured FAQs about trust settings. We knew that the shared mailbox had to be set as the default profile.

Solution: Outlook default profile

But in this case, the data file couldn’t be accessed, as the primary account’s data file was set as default. After changing the shared mailbox to the default data file, we were finally able to send e-mails!

Solution: Outlook default data file

This also explains why the Outlook profile was getting corrupted. It tried to access the data file from the primary account with the credentials of the shared mailbox, which is why the Outlook applications couldn’t access the data file. Another issue is that the e-mails were in the wrong Outbox folder (see issue #1) and when we deleted them, they appeared in the Bin of the primary account instead of the shared account (i.e. the sender).

Automation

Once we set up the Outlook application correctly, we had to make a few adjustments to the automation.

Firstly, there is an Outlook “From” option in the “Send e-mail” activity. If left empty, the automation will use the default Outlook profile in the Outlook application. We noticed that when the shared mailbox account was used as default, the automation would crash. We decided to leave this field empty because the shared mailbox was set up as the default profile + data file in the Outlook application.

Solution: Use default account

Secondly, the automation is too performant to send e-mails in Outlook. A delay needs to be added between sending each e-mail. This is very important when sending multiple e-mails at once, as it prevents the automation from creating a new e-mail item while the Outlook application is busy sending the previous one. To be on the safe side, a five-second delay must be added to make sure the e-mails are created and sent correctly. (A shorter delay may also work; this requires some finetuning.)

Solution: Add delay while sending mails

Conclusion

In this blog post, we hope we could demonstrate how we’re dependant of 3rd party programs where supplementary knowledge is needed. In this particular case, it comes in handy to know a bit about how Outlook works – especially when using a shared mailbox!

We might be Hyperautomation experts, but this was a good example of how programs can cause problems with our automations.

We hope that you had a great time reading through our blog. Meet us in the comments down below and kindly share your feedback or thoughts. Follow my colleague Jana De Klerk and Cedric Verstraeten to stay informed of our latest blog posts.

Thank you,
Jana & Cedric