We used to use the native UiPath.mail.activities.savemailattachments activity to save files on a shared folder and this worked. But now we are retrieving the mails by office 365 activity and we are having a problem. so we changed from native outlook activities to retrieve and save to Office365 (instant connection, is a little faster to retrieve mails)
When using the Download Email attachments activity by MicrosoftOffice365, we cannot use the same shared folder as input for the Destionation Path, it tells us that the path doesn’t exists while it does.
I’ve tried converting the 365mailmessages to standard mailmessages and this doesn’t get the attachments for some reason. When using “Data\Temp” as a path it works in test. But doesn’t when publishing to orchestrator and running it unattended. Even though production Server has connection to the shared drive.
This issue usually happens because the Office 365 activities run under the unattended robot’s user context, and that user doesn’t recognize mapped drives like Z:. The best approach is to use the full UNC path instead, for example: “//ServerName/SharedFolder/SubFolder” instead of a mapped path.
Also, make sure the Windows account used by your unattended robot has both read and write permissions to that shared folder. You can verify this by logging in with the same account and manually creating a file in that location.
Avoid using relative paths like Data\Temp, as these resolve differently in unattended runs. Always use absolute paths.
If you still need to save attachments and the conversion from 365 mail messages doesn’t bring them over, it’s usually better to handle them directly with the Office 365 activities once the path access is fixed.
Hi Rishabh, thank you very much for your reaction. We have been testing with the full UNC path, while this works with the native outlook activity and we can’t use the native activity because that doesn’t work for 365mailmessage variable, when I use the UNC path with the MicrosoftOffice365 outlook activity to download attachment, it doesn’t recognize it.
Hello,
This is a limitation with the Microsoft Office 365 activities. The Download Email Attachments activity doesn’t always recognize UNC network paths, even though they work fine with the native Outlook activities.
A reliable workaround is to first download the attachments to a local folder, such as:
C:\Temp\EmailAttachments
and then use a Move File or Copy File activity to transfer them to the shared folder afterward.
Alternatively, you can map the network drive at runtime before using the download activity by running a command like:
net use Z: \Server\Share /persistent:no /user:domain\user password
and then save the files to Z:\FolderName. Make sure the robot user has the required permissions to access that location.
At the moment, saving locally first and then moving the files is the most consistent and stable solution.
Hi,
As far as I understand Office 365 activities use cloud-based Microsoft Graph API calls that don’t fully support or validate UNC network paths in the local Windows environment anyhow I’m glad I was able to help you.
Cheers!!