activities

latest

false

Productivity Activities

Last updated Sep 13, 2024

How to connect to Microsoft 365 activities

Overview

Microsoft 365 activities have different authentication flows that you can choose from. Your choice is dependent on: the type of automation mode you plan to run (attended or unattended), the type of projects you want to build (cross-platform or Windows), the type of permissions you want to grant (delegated or app-only), and your application authentication requirements (consult with your administrator if you're unsure which authentication requirements apply to your application).

Use the table below to understand the basic differences between each authentication type:

Microsoft Authentication flow	Microsoft 365 Scope - Authentication type	Integration Service connection	API permission type
OAuth 2.0 authorization code flow	Interactive Token - public app	OAuth 2.0 Authorization code	Delegated permissions
OAuth 2.0 authorization code flow	Interactive Token - BYOA	Bring your own OAuth 2.0 app	Delegated permissions
Integrated Windows authentication (IWA)	Integrated Windows Authentication	N/A	Delegated permissions
Username and password	Username and password	N/A	Delegated permissions
OAuth 2.0 client credentials flow	Application ID and secret	N/A	Application permissions
OAuth 2.0 client credentials flow	Application ID and certificate	N/A	Application permissions

Delegated permissions versus application permissions

To understand the differences between delegated and application permissions, see the Microsoft official documentation: Comparison of delegated and application permissions.

Briefly, the differences are as follows:

With delegated permissions, the application impersonates a user and acts on the user's behalf. The application can access only what the signed-in user can access.
With application permissions, the application acts on its own, without a signed-in user. The application can access any data that its permissions are associated with.

For both delegated and application permissions, you can restrict what the application can and can't access using the scopes defined when you create the app. Refer to Scopes and permissions in the Microsoft documentation.

Multitenant versus single-tenant applications

Both Microsoft 365 Scope and Integration Service connections support single tenant applications and multitenant applications. To learn the difference between the two, refer to Who can sign in to you app? in the Microsoft official documentation.

Azure environments

Both Microsoft 365 Scope and Integration Service connections support multiple Azure environments:

Connections through the Scope activity support: Azure, Azure Global, China, Germany or US Government. The default value is Global.
Connections through Integration Service support: Default, US Government L4, US Government L5, and China.

Integration Service connections

Integration Service connectors use OAuth 2.0 authorization code flow with delegated permissions.

The Microsoft 365 modern activities and triggers establish an authenticated connection to the Integration Service Microsoft OneDrive & SharePoint and the Microsoft Outlook 365 connectors. To learn more about Integration Service connections, refer to Set up Integration Service connectors.

When you connect to the Microsoft connectors in Integration Service, you have the option to use the standard UiPath public application (with a set of default, non-configurable scopes) or create your own application with Microsoft and customize the scopes you need.

Microsoft 365 Scope connections

The Microsoft 365 Classic activities establish an authenticated connection to your Microsoft 365 applications via the Microsoft 365 Scope activity.

The activities need authorization from the Microsoft identity platform. To enable authorization, you first register your Microsoft 365 application in your Azure Active Directory. When registering your application, you assign Microsoft Graph API permissions to specify the resources your Robot can access on your behalf.

After registering your Microsoft 365 application, Azure Active Directory assigns a unique application (client) ID that you enter in the Microsoft 365 Scope activity. The Application ID is used to collect the necessary information about your registered app to initiate authentication and get the access token to establish the connection.

When you add an activity to Microsoft 365 Scope, its required scopes are automatically detected. You can also choose to allow additional scopes.

Interactive token

Overview

Runs: as a user.
Scenario: attended automation.
Delegated permissions.

Note: This is the same authentication method supported in Integration Service, either through the public UiPath App or a private custom application (Bring your own app method).

Details

When registering your application, you must select an application type. For interactive token authentication, use a mobile/desktop application (which uses OAuth 2.0 authorization code flow).

The Interactive Token authentication type can be used for attended automation and when multi-factor authentication (MFA) is required. This is the default option and what we use in our examples. If you're interested in trying out the activity package, this option is easy to configure and works well for personal accounts (using the default redirect URI noted in step 7 of the Register your application section of the Setup guide).

You have the option to register and use your own Azure app (i.e., OAuthApplication = Custom) or the one provided by UiPath (OAuthApplication = UiPath).
When you run the Microsoft 365 activity for the first time using this authentication type, you are prompted to authorize access to the resources (you granted permissions to when registering your app) via a consent dialogue box. See Get access on behalf of a user.

If you select this authentication type in Microsoft 365 Scope, leave the Username, Password, and Tenant fields empty.

Integrated Windows Authentication (IWA)

Overview

Runs: as a user.
Scenario: unattended automation.
Delegated permissions.

Note: This authentication type does not work when multi-factor authentication (MFA) is enabled. If your application requires MFA, you can run attended automation using the Interactive Token authentication type or unattended automation using Application ID and Secret and Application ID and Certificate. Application ID and Secret and Application ID and Certificate authentication types are appropriate for unattended automation and work regardless of whether the MFA is enabled or disabled.

Details

The Integrated Windows Authentication authentication type can be used for unattended automation. This option can apply to Windows hosted applications running on computers joined to a Windows domain or Azure Active Directory.

When registering your application, you must select an application type. For IWA authentication type, you must use a mobile/desktop application (which uses OAuth 2.0 authorization code flow).

Works only for federated users and if your registered Azure application is configured to support IWA. Doesn't work for multi-factor authentication (MFA). See details here: IWA on GitHub.
You should only select this option if your registered application is configured to support Integrated Windows Authentication.

If you select this authentication type in Microsoft 365 Scope, leave the Username and Password fields empty. The Tenant field is optional.

Username and Password

Summary

Runs: as a user.
Scenario: unttended automation.
Delegated permissions.

Details

This authentication type is provided only for legacy reasons. We do not recommend using this option, as it goes against the principles of modern authentication. It doesn't work for multi-factor authentication (MFA). See details here: User & Password on GitHub.

Although it is not recommended by Microsoft, you can use this authentication type in public client applications. Using this authentication type imposes constraints on your application. For instance, apps using this flow won't be able to sign in a user who needs to perform multi-factor authentication (conditional access). It won't enable your application to benefit from single sign-on either.
The ApplicationID property is required when selecting the Username and Password authentication type. You can register your Microsoft 365 Application using your personal, work, and/or school account.

Application ID and Secret

Summary

Runs: as background service.
Scenario: unattended and unattended with MFA enabled.
Application permissions.
Recommended for unattended executions or when you want to access the Microsoft Graph API as an application (a background service / daemon) without a signed-in user.

Details

When registering your application, you must select an application type. For application ID and secret authentication type, use a confidential/web application (which uses OAuth 2.0 client credentials flow).
The appropriate API permissions must be configured for the Azure application in order for Microsoft 365 activities to work properly (e.g. the application permissions Group.Create, Group.Read.All and Group.ReadWrite.All should be configured for Microsoft Graph when using Groups activities).
A single organization can have multiple application (client) IDs for their Microsoft 365 account. Each application (client) ID contains its own permissions and authentication requirements. For example, you and your colleague can both register a Microsoft 365 application in your company's Azure Active Directory with different permissions. Your app can be configured to authorize permissions to interact with files only, while your colleague's app is configured to authorize permissions to interact with files, mail, and calendar. If you enter your application (client) ID into this property and run attended automation, the consent dialogue box would be limited to file permissions (and subsequently, only the Files activities can be used).
Some activities can't be used with this type of authentication because the corresponding Microsoft Graph API does not support application permissions (e.g. Find Meeting Times).
For email activities, it is mandatory to specify a value for the Account parameter (i.e. which mailbox of all tenant's mailboxes do you want to use).
Use Sites.Selected application permission to allow the application to access just the specific SharePoint site collections rather than all.
When using this authentication type, the application has access to all mailboxes from your tenant, the reason being that application API permission Mail.Read means Read mail in all mailboxes and Mail.ReadWrite means Read and write mail in all mailboxes. One solution is to restrict Application permissions to specific mailboxes, so the application has access only to the specified mailboxes. For more information, see Scoping application permissions to specific Exchange Online mailboxes.

Application ID and Certificate

Summary

Runs: as background service.
Scenario: unattended and unattended with MFA enabled.
Application permissions.

Details

When registering your application, you must select an application type. For application ID and certificate authentication type, use a confidential/web application (which uses OAuth 2.0 client credentials flow).

This authentication mtehod is similar to application ID and secret, but it uses a certificate as a secret instead of a client secret string.

Using certificates

To authenticate using a certificate as a secret, take the following steps:

In the the Azure portal:
- Locate your registered Microsoft 365 application.
- Select Certificates & secrets and upload your certificate (public key) file. It can have one of the following file types: .cer, .pem, .crt.
Convert the raw contents of your .pfx file representing the certificate to a base64 string. You can use a web-based tool like Base64.Guru or assign the Convert.ToBase64String(System.IO.File.ReadAllBytes(pfxFilePath)) value to a String variable.
In the Microsoft 365 Scope activity:

Set Authentication Type to Application ID and Certificate.
Set Certificate as Base64 to the base64 representation of the certificate.
If a password is required to use the certificate, set the value for the Certificate Password property as well.

How to use Microsoft 365 activities without Integration Service connections

About

You can now use the newer Microsoft 365 activities even if you don't have Integration Service, through Microsoft 365 Scope.

The Microsoft 365 activities designed specifically for Integration Service feature a Connection field, which enables you to choose a connection created through an Integration Service connector. When used inside Microsoft 365 Scope, the activities simply inherit the connection information from the Scope.

Authentication and projects types matrix

Microsoft 365
	Cloud		On-Prem
	Microsoft Office 365 Application Scope	Integration Service	Microsoft Office 365 Application Scope	Integration Service
Cross-platform
App ID & Certificate
App ID & Secret
OAuth - BYOA
OAuth - UiPath App
Username & Password
Integrated Windows Authentication
Windows
App ID & Certificate
App ID & Secret
OAuth - BYOA
OAuth - UiPath App
Username & Password
Integrated Windows Authentication

Connection methods

There are two ways to set up a connection in the Microsoft 365 Scope activity.

Connection method		Description	Benefits	Disadvantages
Asset Note: Recommended.		Uses an Orchestrator Asset to store the connection together with the Scope configuration. The asset is a JSON format. Every time it's used, the activity retrieves the configuration from the asset. Based on asset configuration, the Scope behaves differently; it identifies the authentication type and hides unnecessary fields. If the asset JSON isn't set properly, it prompts a validation error.	The activities benefit from design time lookups and can discover files, folders, lists, ranges, and others. The connection is easily transferable, as credentials aren't passed from one user to another in plain text. Can be configured by an Admin. It's more secure, because the credentials don’t reach the Studio workflow.	Requires an advanced user to configure the Asset. Not easy to set up by a Citizen Developer.
Properties Panel		Use the existing Properties panel to configure the connection credentials. The configuration can be added in plain text or through variables.	Easier to use. Keeps backward compatibility.
	Configuration through plain text Note: Not recommended.	Configure the Properties panel with plain text values.	The activities benefit from design time lookups and can discover files, folders, lists, ranges, and others.	Less secure, because the credentials need to be passed between users in plain text.
	Configuration through variables	Configure the properties panel with variables.	More secure, because the credentials don’t reach the Studio workflow.	The activities can't discover any resources at design time.

Microsoft 365 Scope asset format

Standard asset format

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default" | "Global" | "China" | "Germany" | "USGovernment" | "USGovernmentDOD",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "",
        "TenantId": ""
    }
}{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default" | "Global" | "China" | "Germany" | "USGovernment" | "USGovernmentDOD",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "",
        "TenantId": ""
    }
}

UiPath application asset configuration

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "f2f43f65-16a6-4319-91b6-d2a342a88744",
        "TenantId": ""
    }
}{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "f2f43f65-16a6-4319-91b6-d2a342a88744",
        "TenantId": ""
    }
}

Custom application asset configuration

Note: This is just an example. Configure your own application and retrieve the required OAuth2AppData.

{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "d47f7253-65ae-58n5-ag04-26109734e6de",
        "TenantId": "3ce4ef03-chb1-871f-94b0-345136965f10"
    }
}{
    "CertificateAsBase64": "",
    "CertificatePassword": "",
    "ClientSecret": "",
    "Environment": "Default",
    "Mode": "interactive" | "integrated" | "uap" | "appidsecret" | "appidcertificate",
    "OAuth2AppData": {
        "ApplicationId": "d47f7253-65ae-58n5-ag04-26109734e6de",
        "TenantId": "3ce4ef03-chb1-871f-94b0-345136965f10"
    }
}

Limitations

The following features are not available when using activities inside Microsoft 365 Scope: triggers, bindings, and override experience.

Token refresh

There is no service available to refresh your connection tokens, like the one available in Integration Service.

If the Authorization Token isn't refreshed for a certain number of days, it expires, and you must re-authenticate. To avoid the expiration of authorization tokens, run a robot with that specific connection. Running an automation with the Scope activity refreshes the authorization token.

Additional OAuth 2.0 resources: