I’ve been trying to figure out a way to fully automate getting emails from a service accounts Outlook but am struggling and looking for any suggestions. I set up an integration connection to a service account in Orchestrator and a trigger for when new email comes in. I’m following the documentation for using the MicrosoftOffice365.Activities pack located here: https://docs.uipath.com/activities/docs/about-the-microsoft-office-365-activities-pack.
I am able to get into the Office 365 scope but when it calls me Get mail activity it always fails. I’ve tried checking all the boxes, or just some under the options. Each time I get the following error code:
Error: Get Mail: Code: Request_BadRequest Message: Unexpected segment DynamicPathSegment. Expected property/$value. Inner error: AdditionalData: date: 2023-03-10T20:43:32 request-id: b211aa41-61a6-497a-b0ca-57a42cd2f390 client-request-id: b211aa41-61a6-497a-b0ca-57a42cd2f390 ClientRequestId: b211aa41-61a6-497a-b0ca-57a42cd2f390.
I eventually am only looking for specific emails to grab the subject line. Does anyone know what the property/$value is and how to fix this? I believe I need to put something in the query box but unsure how to write it. I do not want to open the Outlook app for this to work. This will be running on an unattended machine. Any suggestions are greatly appreciated.
Good enough…I hope you would have given all the scopes as required as well…as mentioned in the documentation
Now I hope your appid secret and tenant are proper …I would recommend reverifying…Apart from that you dont need to provide account in the username field that needs to be populated if you are using username and password authentication…and oauth application please try using UiPath and check …
Coming to get mail username should include domain as well and not only the username eg:email@example.com
If all of these are correct then if you are getting error first run the process in debug mode and open locals panel and from there open the exception details and check it might have extra information like what exactly might be missing of the error
Apart from that try changing the version of the office 365 activities and check if its working
Lets us know the progress would be happy to help if needed
There are the permissions the app has inside of Azure AD. Per the Microsoft Office 365 scope document, I have to set the Oauth to Custom, otherwise the App ID and tenant are ignored. I did try anyway with the same error as before.
The variable account is written as domain/user. I also downgraded the activity pack to 2.0.1 and still no luck.
Running in debug mode these are the exception details:
Create an Orchestrator service account: Before you can start automating Outlook, you need to create a service account in Orchestrator that has access to the mailbox you want to automate.
Set up the activity properties: In the properties panel for the Get Outlook Mail Messages activity, configure the following properties:
Account: Select the Orchestrator service account you created in step 1.
MailFolder: Choose the folder you want to retrieve emails from.
IncludeSubfolders: If you want to include subfolders in the retrieval process, set this property to True.
Filter: You can use this property to filter the emails that are retrieved based on specific criteria. For example, you might only want to retrieve emails that contain a certain subject or that were sent by a particular sender.
I did try with just the email address. When I do that, I get an error of access denied. I’ve tried this will versions 1.14.1 and above with the same results.
My service account is set up in Orchestrator. I’m using it in other automations with no issue. It is set up as a robot role, and unattended setup. I have it set to run on a virtual machine that it logs into itself. It is set up in Azure AD as a regular user with access to email.
I tested using the Microsoft Graph Explorer tool and was able to get the desired results I am after using the service accounts email. So I know this is possible, but I am not able to get it working with any of the activities.
here are a few common issues that could prevent activities from working with your service account:
Authentication: Ensure that your service account has the appropriate permissions to access the application or resource that you’re trying to automate. Additionally, double-check that the authentication method you’re using (e.g., OAuth2.0, API key, etc.) is correct.
Configuration: Verify that the activities are configured correctly and that any required fields or parameters are populated. For example, if you’re using an activity to send an email, make sure that the email address and subject line are entered correctly.
Environment: Ensure that the environment in which you’re running the automation (e.g., virtual machine) has the necessary software and libraries installed to support the activities you’re using.
Troubleshooting: If the activities are still not working, try troubleshooting the issue by checking logs or error messages, reaching out to support forums or documentation, or seeking assistance from the automation vendor.
if none of the above solutions work, it’s possible that the issue is related to access permissions. In this case, it may be necessary to involve your IT department or system administrator to ensure that your service account has the appropriate access rights to the application or resource you’re trying to automate.
it’s possible that there may be an issue with the installation or configuration of the package. Here are a few potential solutions you can try:
Verify package installation: Double-check that the activity package is installed in your Studio environment. You can do this by going to the Manage Packages option in the project tab and checking the Installed tab. If the package is not listed, you may need to install it manually.
Update package version: If the activity package is installed but not loading, try updating the package to the latest version. You can do this by going to the Manage Packages option in the project tab and checking the Available packages tab. If an update is available, select it and click Install.
Repair Studio installation: If neither of the above solutions work, try repairing your Studio installation. You can do this by going to Control Panel > Programs and Features > UiPath Studio, and selecting Repair.
Contact vendor support: If the issue persists, you may need to contact the vendor’s support team for additional assistance. They may be able to provide more specific guidance on resolving the issue and ensure that your Studio environment is configured correctly.
Thanks for the troubleshooting. I do currently have a case open with support and after two phone calls we still are unable to figure it out. I was able to use the Get Outlook Mail messages activity under Outlook 365 scope. However, it was determined that the permission would only be good for 30 days which is not acceptable for automation. One thing that has not made sense to me is support wants me to use the Microsoft office 365 scope. Per the documentation I should not have to use the scope as it has been replaced with the integration services activities. My email trigger works great from the integration services on this service account. So why does the corresponding activities inside Studio not work the same.
The authentication has been confirmed with the app, tenant and secret id. I had the Azure AD admin configure the application access to this specific service account following the Microsoft document
After my most recent call with support they believe this may be due to having a hybrid AD, more research to come.
My end goal is to read the subject line of emails from a service account and populate a queue in Orchestrator. If Integration services can kick off a process from Orchestrator on a service account, I don’t see how it is this difficult to get a process to read those emails.
I do not have Studio installed on my unattended machine so I am unable to watch the local panel. I’ll have my sys admin verify firewalls again just to be sure.
Found the issue. In Azure AD, you have to grant admin consent in the API permissions. We had initially held off on this as the app can access all mailboxes at first unless you run the powershell script from Microsoft to limit the access. I did test on another mailbox and confirmed the access was denied to it.