For the complete documentation index, see llms.txt. This page is also available as Markdown.

Microsoft Entra ID Connector

Version 1.1.0 · Vendor: equipme · Module: equipme.microsoft.entraid

The Microsoft Entra ID connector lets your workflows manage Microsoft's identity and access platform, formerly Azure Active Directory. It covers the everyday administration work — users, groups, devices, licenses, directory roles and app registrations — and adds a family of monitors that watch your tenant for you: expiring app secrets, inactive accounts, missing MFA registration and more.

equipme talks to Microsoft Entra ID in three different places. This section is about the workflow connector, which writes into Entra from your flows.

If you are looking for importing employees into equipme from Entra, see HR-Sync. If you are looking for signing in to equipme with Entra credentials, see Single Sign-On.

Setting up the connection

The connector uses OAuth2 with Microsoft sign-in and delegated permissions. The first time you use one of its components, you are asked to sign in with a Microsoft account.

Three things are worth knowing before you start:

The account matters. Delegated permissions never widen what an account is allowed to do. The account you sign in with needs the matching Entra ID role for the task — User Administrator for user management, Cloud Application Administrator for app registrations, and so on.

Each component asks only for what it needs. Components request their own scopes, so the first use of a new component may require signing in again and confirming admin consent.

If you see "Insufficient privileges to complete the operation", the connection was authorised before the component you are now using existed. Disconnect the connection in the flow, sign in again and confirm admin consent so the new scopes end up in the token.

What this section contains

Start with Working with the Connector. It explains the patterns that repeat across every component — how lists are returned, how monitors report, how triggers behave — so the component pages themselves stay short.

After that, the pages are grouped by area: users, groups, devices, licenses, directory roles, app registrations, authentication, and monitoring. Workflow Examples shows how these combine into complete processes, and Required Permissions lists the scopes each area needs.

Was this helpful?