We are using Azure app id and tenant id for authentication, with OAuth Application set to custom. This morning I was working on an automation and everything was working fine, getting and updating items in Sharepoint online. I commented out a couple sequences and started working on a new sequence, and suddenly it was failing (it was popping up the “request access from Azure app admin” window).
After doing some troubleshooting, our admin saw that it was requesting Sites.Read.All and we didn’t have that in our Azure app registration because we had Sites.ReadWrite.All which seems like it should cover Sites.Read.All.
So I’m wondering how it’s determining which authentication scope to use. The new sequence I started working on only had the Get List Info and Get List Items activities inside it. The other two sequences which included Update Single List Item had been working fine, so I commented them out.
Is it dynamically looking at what activities are inside the 365 scope to determine which authentication scope to use? Is it because I only had “get” activities and no “update” activities that it started using Sites.Read.All?
You got it right. Each activity has a list of necessary scopes to work fully. M365 Scope tries to join all the scopes of the activities within the M365 Scope Activity and asks for the minimal necessary permissions for all the functionalities of the activities to work. Yes, it is done dynamically as you add or remove activities.
You can control the scopes asked from the “Authentication Scopes” dropdown.
In addition, the workflow can work even with fewer scopes than the ones asked by the activities. For example, a Send Mail doesn’t need the Mail.Send the scope if it is only saving it to draft, but we cannot cover all the possible scenarios. That is why the activities are set to ask for the minimal scopes for all the features to work.
Thank you for the explanation. It now makes perfect sense what happened yesterday.
Another issue…
We use Assets to store the Azure App ID and Tenant ID. So we get the Assets into variables and put those variables into the 365 Scope activity - this means we get the “authentication parameters could not be read, you must provide a literal value for ApplicationId/TenantId in order to use design time services” messages, so we don’t see the Authentication Scopes property.
If I put in literal values, select the Authentication Scopes, then put in the variables so the Authentication Scopes property disappears, are the selections I made still stored even though the Authentication Scopes property disappears?
It would be great if we could define defaults for those two variables and then the 365 Scope would pick up the default values for those variables and allow us to select the Authentication Scopes. This gives us the best of both worlds - we can use Assets/variables so we don’t have anything hard-coded, but we can also use the design time services.
We understand your request and it is more than valid. That is why we thought of something better.
M365 Scope allows you to set the Asset directly in the Scope.
You can specify the Connection method - Asset.
You specify the asset from the Orchestrator. You need an Asset in a special JSON format where you specify all the Authentication Details: Asset Format
If it is an Interactive Method, you can use an existing Connection, create a new Connection, or delete the existing Connection.
You have the scopes that we’ve talked about.
In addition to this.
5. You can specify where the “Connection” (Refresh Token and other details to be stored) so they can be reused in multiple automations.
6. As we cannot read at Design Time Credentials Assets, we have defined a Runtime connection asset where you can put a Credential Asset. So, in Production everything is under Credentials.
The big benefits of this approach are that you have Design Time services, and you don’t need additional Get Asset/Credentials activities.
That does not help us, and frankly isn’t a good design. Again, we don’t hard-code things. So hard-coding the Asset into the “Runtime connection assets” property doesn’t do anything for us. We just need the default value of the variables for App ID and Tenant ID to be used - just like you do in dynamic selectors. This gives us the design-time features, but also means at run-time the values are retrieved from the Asset whose name is specified in the config file.
We are also on-prem (for now, anyway) and therefore we don’t have access to things like Integration Services (if that’s what you’re using in your example). We use App ID and Tenant ID directly in the scope, with delegated permissions in the Azure App.
HI @postwick , Not sure if this will be helpful for you, but I wanted to share our approach.
In all my projects, we’ve used Office 365, and here’s the configuration we typically follow. Since we have two levels of code reviews, we’re not allowed to hardcode values directly into the RPA workflows. All values must come either from the Config file or from Orchestrator Assets.
Quick note: Currently we are in Studio version 23.10.3
We use the Property Panel as the connection method.
Thanks. I’m aware how to connect. That wasn’t my question. Authentication scopes look like Sites.Read.All or Sites.ReadWrite.All and are a thing for delegated permissions inside the Azure application. It has nothing to do with how you authenticate with the 365 Scope activity.
You don’t need to hardcode anything in the Runtime connection assets. You can just put a variable with the path from the Asset where the JSON is.
To have these “Default” values, activities must still store the App ID and Tenant ID, even if you don’t see them. So, we prefer not to hide things behind. For dynamic selectors, we do calls at Design Time to discover the information and than we cache it for some time.
