> ## Documentation Index > Fetch the complete documentation index at: https://docs.introw.io/llms.txt > Use this file to discover all available pages before exploring further. # Allow Microsoft sign-in for a partner's organization > What a partner's IT admin grants in Microsoft Entra ID before their people can sign in to your portal with Microsoft, and how to fix the "Need admin approval" screen. > For partner ops whose partner cannot sign in with Microsoft, and for the IT admin at that partner who has to fix it. Microsoft sign-in works for most partners on the first try. At some partners, nobody gets in at first: everyone sees a Microsoft screen asking for admin approval, or lands back on the login page with "Sign-in was canceled". That is not a problem with your portal or with their account. Their IT team has turned off the right of regular users to approve new apps, so an admin has to approve Introw once for the whole organization. Send this page to that admin. ## What you'll achieve Everyone at the partner's organization can sign in to your portal with their Microsoft work account. The admin approves once, and nobody at that partner has to ask again. ## Why it happens Your portal uses Microsoft sign-in through Introw's app in Microsoft Entra ID, the identity service behind Microsoft 365. The first time someone from a company signs in, Microsoft checks whether that person may approve the app themselves. Many organizations only let admins approve apps, which is a normal security setting. In those organizations, the first sign-in stops at a consent step until an admin grants approval for everyone. The approval covers Introw's app, not one vendor's portal. Once a partner's admin has approved it, their people can sign in with Microsoft to every portal that runs on Introw, and to [partners.introw.io](https://partners.introw.io). ## What Introw asks for Introw only asks Microsoft to sign the person in and share their basic profile. It does not read mail, files, calendars, contacts, or anything else in the partner's Microsoft 365. | Permission | What Microsoft shows | What Introw uses it for | | ---------- | ----------------------- | ------------------------------------------- | | `openid` | Sign you in | Confirm the person signed in with Microsoft | | `email` | View your email address | Match the person to their portal access | | `profile` | View your basic profile | Show their name in the portal | These are delegated permissions: they only apply while the person is signed in, and only to that person's own profile. ## Steps for the partner's IT admin Use an account that holds **Global Administrator**, **Cloud Application Administrator**, or **Application Administrator** in Microsoft Entra ID. Open the vendor's partner portal and choose **Sign in with Microsoft**. On the Microsoft consent screen, tick **Consent on behalf of your organization**, then select **Accept**. Microsoft only shows this checkbox to admin roles. If your organization uses admin consent requests, you can instead approve the pending request under **Enterprise applications** > **Admin consent requests** in the [Microsoft Entra admin center](https://entra.microsoft.com). In the Microsoft Entra admin center, go to **Enterprise applications** and open the app named on the consent screen. Under **Properties**, make sure **Enabled for users to sign in?** is set to **Yes**. If **Assignment required?** is set to **Yes**, only assigned people can sign in, so assign the users or groups who need the portal under **Users and groups**, or set it to **No**. If a Conditional Access policy applies to all cloud apps, confirm it does not block this app for the people who need the portal. A policy that requires multifactor authentication or a compliant device still works: people sign in the same way they sign in to Microsoft 365. ## Verify it worked Ask one person at the partner who was blocked before to open the portal and choose **Sign in with Microsoft**. They go straight through without a consent screen and land in the portal. If they now reach the portal but see that they have no access, sign-in works and the remaining step is on your side. See [How a contact actually gets in](/features/portal/portal-access/technical#how-a-contact-actually-gets-in). ## Microsoft error codes Microsoft shows an `AADSTS` code on its error screen, and it tells the admin which step to look at. | Code | What it means | Fix | | -------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------- | | `AADSTS65001` | Nobody has approved the app for this organization yet | Grant consent for the organization | | `AADSTS90094` | Approving this app needs an admin | Grant consent for the organization | | `AADSTS65004` | The person declined the consent screen | Sign in again and accept, or have an admin grant consent for everyone | | `AADSTS50105` | The app requires assignment and this person is not assigned | Assign the person or their group, or set **Assignment required?** to **No** | | `AADSTS53003` | A Conditional Access policy blocked the sign-in | Adjust the policy for this app | | `AADSTS650051` | A temporary Microsoft issue during the first approval | Try again. It clears on retry | ## While the partner's IT team works on it If the portal also offers **Email** as a login method, people at that partner can sign in with a one-time code sent to their work email in the meantime. Their access is the same either way, and they can switch to Microsoft sign-in once their admin has approved it. Login methods are set in [Set up portal access](/features/portal/portal-access/guides/set-up-portal-access).