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), whether you use Integration Service or not, 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	Robot type - Attended	Robot type - Unattended	API permission type
OAuth 2.0 authorization code flow	Interactive Token - public app	OAuth 2.0 Authorization code		(only with Integration Service)*	Delegated permissions
	Interactive Token - BYOA	Bring your own OAuth 2.0 app		(only with Integration Service)*	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
	Application ID and certificate	N/A			Application permissions

^* Integration Service keeps the connection token alive by refreshing the token. After a certain period of time, you must manually refresh the connection by re-authentication.

To learn about the specifics of each option, see:

• Connect with Integration Service

• Connect with Microsoft 365 Scope

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.

Tip: Refer to Working with activity scopes to learn how to control permissions using activity scopes.

Admin consent

Many organizations require an administrator's consent before creating a connection to an external application. The admin consent workflow requires an admin to approve the app registration to specific users or groups before a connection is established. For more information, see Overview of admin consent workflow and User and admin consent in Microsoft Entra ID 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. For details, see Microsoft Graph and Graph Explorer service root endpoints.

Microsoft National Cloud	Environment in Integration Service	Environment in Microsoft 365Scope
Microsoft Graph global service	Default	Azure, Azure Global
Microsoft Graph for US Government L4	US Government L4	US Government
Microsoft Graph for US Government L5	US Government L5	N/A
Microsoft Graph China	China	China