Read email through Microsoft office 365 activities

Please check the message i have shared and let me know if any queries. " [Office 365 Scope setup]


Please use office 365 activities instead of HTTP Request in UiPath environment

1 Like

which one? Is it just the scope?

Sorry I just saw that activities is a hyperlink. I am having trouble reading an excel from sharepoint. I need to use the Office 365 scope to access the sharepoint excel. i got it working as attended. But having troube with unattended where it is asking for the client secret. I have made the secret. But no where to pass it in. So I am using the HTTP request. But I am unable to get it working. How did you resolve this error of client secret not in body?

1 Like

Can anybody share what the preferred solution to this is? I don’t want to believe that I have to rebuild the O365 connector using HTTP requests.

Please check the message i have shared and let me know if any queries. " [Office 365 Scope setup]


Thank you for the attempt to help! Unfortunately the link is not working for me.

Office 365 Scope setup - UiPath Community Forum.pdf (347.1 KB)
Please check and let me know if any issues

@tharuler @kkrehl what version of MicrosoftOffice365.Activities are you using?
I had the same issue, and everything seems to work correctly for me with version 1.1.2.

I am using this version and working fine.

@Kartheesan I have been trying to get this to work as well for a few weeks. It looks like in your attachment you had to edit “allowPublicClient” to be True. Is that a setting for your Application in Azure? I couldn’t find a setting in the Office365 Scope activity for this. Thanks for your consideration.


To resolve this error when using the unattended UsernameAndPassword authentication method:

The request body must contain the following parameter ‘client_assertion’ or ‘client_secret’

You need to go to the Authentication blade of your Azure App registration and set it as a public client.

However, the next issue is that the unattended user has not consented to the requested permissions unless you first run it at least once via the InteractiveToken method to see the consent dialog, or have an administrator user grant consent on behalf of the organization. You can then switch it back to UsernameAndPassword.


Now that I have documented this, is seems the UiPath Microsoft Office Scope setup documentation is, well, somewhat missing information ?

Anyway, this is what I just came up with today going through this. I think this is accurate as it got me going:

  • Within Azure Portal, setup the App Registration with:
    • “urn:ietf:wg:oauth:2.0:oob” added to Redirect URIs for “Mobile and desktop applications” … do not check any of the other default Redirect URIs
    • Public Client = Yes
    • Client Secret created and recorded
    • API Perms setup appropriately
  • Get Admin Consent performed on the API Permissions for the new App Registration.
  • Setup a Studio workflow using the Microsoft Office Scope Activity and some related activity to perform like Get Mail.
    • The Scope Activity needs:
      • The Authentication Type to be “InteractiveToken”
      • The password field uses the client secret value (annoying the password field is a string)
  • The first time the workflow is run manually:
    • The Scope activity will prompt for user approval of the App Registration. Once done, the steps inside the Scope activity are hit next.
    • Steps inside of the Scope Activity appear to be where Admin Consent matters … like Get Mail.
    • If Admin Consent is not performed, those steps will fail with a not authorized error.
  • The next time it is run no prompt responses should be required (outside of Admin Consent issues)
  • If desired to use Authentication Type “UsernameAndPassword”
    • The Scope Authentication Type can be changed to “UsernameAndPassword”
    • The Scope password field needs to use the physical account password vs the client secret
    • It should run normally without prompting again.
    • Just not sure why you would want to do this ???

The UiPath Office Scope Setup documentation doesn’t mention the client_secret part that I could find.

I have access to the shared calendars of my colleagues and while registering the app on Azure I have also given permission to access shared calendars. But when I am using Get Calendars activity inside Office 365 scope I am not able to access my colleague’s shared calendars. Please help me with this.

Am I missing anything ?

Everything I mention below is in my experience recently getting the Graph API to allow a Robot to read emails from a Shared Mailbox on Office365. Your milage may vary.

Read my steps above your post again. You will see reference to Admin Consent being mentioned. That is required at least in my experience it was. The column under the “Status” next to “Admin consent req…” will look like this once the Admin Consent has been performed by your Azure Administrator:

I’m no Azure guru at all but I’m pretty confident this is part of your problem. I’m not 100% positive on this part but for email API I discovered User Consent is always required when you run a workflow the first time hitting that App Registration. When you run it the first time, you have to approve that API Permissions from Studio. When you run it the first time and it hits the Graph API, your Studio Icon will start flashing:


You should see something like this to indicate which account you want to run the approval through. If the account with the App Registration tied to it isn’t shown then click on “Use another account”.


You will then be prompted for the password of that account.

Then you will be prompted to confirm the use the API permissions something like below:

Click on the Accept button. In my experience with the Email App Perms and the account which is using the App Registration, you only have to do this once from anywhere. The acceptance of these permissions I’m guessing is stored in Azure somewhere. Since I’ve done the above, using the Mail Graph APIs work with no issues from any of my Robots.

Everything above is what I had to do to get Robots reading a shared mailbox. Not sure if Calendars are similar but thinking maybe !!

I have followed all the steps which you mentioned. I also logged in when launched the process for first time and approved all the permissions. Things are working fine with my mailbox but when i was trying to access shared calendar I was always getting null value.
Anyway after spending some time on this issue I left it and followed some other approach.

Oh then the calendar is different. Can you share what you found maybe sharing a link to the forum post ? I’d be interested in seeing that.

An easy way to do this is to construct a URL to send to an admin user as documented here: Grant Admin Consent. The URL looks like Sign in to your account. There are other methods on the same page, if your customer is more familiar with Azure.

I’d advise using this as the default for an unattended robot, since it is not able to do an interactive login (I suppose it could if you just use UI automation on the login window, but you’d need a parallel process to monitor for that popup).

Hey @lroos, thank you for reading and replying to my reply ! I was hoping someone would :slight_smile: as I’m new to the Azure API security model. What I posted is basically what I figured out reading UiPath Docs (which are somewhat skinny at this level of detail) and more than a few forums posts like this thread.

I need to read the Admin Consent URL you sent over and likely others to grasp what it is indicating.

On the second comment you made, is your comment suggesting that UserAndPassword authentication doesn’t require the user consent path and images like I posted in my reply to gaurav.tiwari ?

Thanks for any clarifications !!

Unfortunately the UsernameAndPassword method will still fail with a 401 error before the user has given consent, it just doesn’t pop up a dialog. However, I think if an admin grants consent for the organisation, then each user in that tenant is no longer prompted for consent (need to confirm) and then this will just work.

As a workaround, you can create a 2nd standalone process with just one 365 scope using InteractiveToken, and have someone run it manually via UiPath Assistant (once off), log in with a 365 account and provide consent when promoted. From then on, that consent will be saved and the UsernameAndPassword method in your main process will continue to work.