Article Summary
Enable the built-in Microsoft sign-in button in AutoRFP so users sign in with their existing Microsoft work account instead of an AutoRFP password. This is a fast setup that doesn't require custom SAML or SCIM configuration.
📝 Note: This enables the built-in Microsoft sign-in button — a fast, one-click setup for most organizations. If your organization needs custom SAML configuration, provisioning via SCIM, or IdP-specific capabilities like My Apps, see Microsoft Entra ID: SSO, SCIM & IdP Setup Guide instead.
Estimated Time
5–10 minutes
Prerequisites
Before you begin, make sure you have:
Administrator permissions in AutoRFP.
Admin permissions in Microsoft / Microsoft Entra ID sufficient to authorize the OAuth connection (you'll be prompted to sign in and grant access when you authenticate).
Confirmation that user email addresses match between AutoRFP and Microsoft — authentication fails if they don't.
Coordination with your team about the upcoming change to how they log in.
‼️ CRITICAL: SSO is an organization-wide change that affects how all users sign in. Once enforced, every user must sign in using Microsoft, and password-based login is disabled.
📝 Note on terminology: Microsoft Entra ID was previously called Azure Active Directory (Azure AD). Some Microsoft screens, error messages, and older documentation still use the old name — Entra ID and Azure AD refer to the same product.
Step-by-Step Instructions
Step 1: Access Organizational Settings
Navigate to Organizational Settings from the main menu.
Select Integrations.
Locate the SSO section.
Step 2: Select Microsoft
In the SSO section, locate the Microsoft card (for organizations using Microsoft 365 / Microsoft OpenID Connect) and select it.
Step 3: Authenticate
Select the Setup button on the Microsoft card.
Sign in using your Microsoft work account credentials in the popup window.
Confirm the signed-in email address matches your current AutoRFP account — authentication fails if the emails don't match.
Grant the requested permissions when prompted.
Step 4: Enforce SSO
After successful authentication, select Enforce SSO.
Review the confirmation message carefully — this is an organization-wide change.
Confirm that you want to enable Microsoft SSO for your organization.
Step 5: Communicate Changes to Users
Notify all users that Microsoft SSO is now active.
Inform them they'll use their Microsoft work account to log in going forward.
Explain what to expect during their next login (see table below).
Please note: AutoRFP will require users with existing passwords to enter their AutoRFP.ai password one more time to transfer them to SSO.
What Changes for Users
Aspect | After enforcement |
Signing in | Users select "Sign in with Microsoft" on the AutoRFP login screen instead of entering a password. |
Passwords | AutoRFP passwords are no longer used for sign-in. Access is governed by the user's Microsoft account. |
First sign-in after enforcement | A user who previously signed in with an AutoRFP password will be asked to enter that password one final time to migrate their account to SSO. This is expected and happens only once. |
Disabling SSO | An administrator can turn SSO back off from Integrations settings. This restores password-based sign-in, but affected users will need to reset their password. [[NEEDS SME CONFIRMATION: does disabling Microsoft OAuth SSO trigger an automatic password-reset email, or must the user request one manually?]] |
🛠️ Troubleshooting
Common problems administrators and users run into when setting up or using Microsoft SSO, and how to resolve each one.
Authentication fails: email doesn't match
The email address on the signed-in Microsoft account doesn't match the email on the AutoRFP account. Confirm the user's AutoRFP account email exactly matches the email Microsoft returns for that account (case is normalized, but the local part and domain must match). [[NEEDS SME CONFIRMATION: can an admin edit a user's AutoRFP account email directly, or does this require contacting AutoRFP support?]]
User signs in with a personal Microsoft account or the wrong tenant
The user selected a personal Microsoft account (an MSA, e.g. an @outlook.com or @hotmail.com address) or a work account in a different tenant than the one your organization authorized, instead of their correct work account. Have them sign out of the incorrect account in the Microsoft popup and choose the right work account, or use "Use another account" to switch. [[NEEDS SME CONFIRMATION: does AutoRFP restrict the OAuth connection to a single Entra tenant, or can any Microsoft account technically complete authentication if the email happens to match?]]
Popup blocked during the Authenticate step
The Authenticate button opens a Microsoft sign-in popup window. If a browser or extension blocks popups for AutoRFP, nothing may appear to happen when the user selects Authenticate. Allow popups for your AutoRFP domain and try again.
💡 Tips & Best Practices
Verify all user email addresses match between AutoRFP and Microsoft before enforcing SSO.
Confirm you have the necessary admin permissions in both AutoRFP and Microsoft before starting.
Notify users in advance of the one-time password migration prompt so it doesn't look like an error.
✋🏼 Common Mistakes to Avoid
Enabling SSO without notifying users — creates confusion and login failures.
Disabling SSO without planning for password resets — locks users out of accounts.
Forgetting that SSO is organization-wide — affects all users immediately, not just admins.
Authenticating with a personal Microsoft account instead of the correct work account.
Related Guides
Need Help?
💬 Live Chat: Available in-app
📚 Learning Centre: learn.autorfp.ai/en