20–40 minutes, including a pilot check to verify your setup before enforcing SSO organization-wide.

This guide is written for an AutoRFP.ai organization Administrator working alongside someone with Application Administrator or Global Administrator rights in Microsoft Entra ID—the permissions required to create Enterprise Applications and configure SAML.

Before you begin, make sure you have:

AutoRFP runs in three regions, each with its own set of SAML connection values.

Using the wrong region's values is one of the most common setup mistakes, so before you make any changes in Entra, confirm which hostname your organization signs in at (app.autorfp.ai, us.autorfp.ai, or eu.autorfp.ai).

The table below lists the values for each region:

📝 Confirm: Both the email claim and the Name ID have been verified end to end in a live Entra ↔ AutoRFP connection.

The screenshots below use user.mail. If your tenant's mail attribute is empty, or differs from the address on the AutoRFP account, use user.userprincipalname instead and map both the email claim and the Name ID to it consistently.

Setting up custom SAML SSO touches three places: the AutoRFP Custom SSO wizard, the Microsoft Entra admin center, and (for user assignment) both. Work through the parts in order.

Select Edit on Basic SAML Configuration and enter the values for your region from the table above:

Select Save.

Expected result: The Basic SAML Configuration panel shows your saved Identifier, Reply URL, and Relay State when you reopen it.

AutoRFP needs one email-shaped claim asserted for each user. In Attributes & Claims, make sure one of the following claim names is sent, mapped to the user's email or UPN:

Set the Name ID (the SAML value that uniquely identifies the user) as follows:

Still on the SAML setup page, copy these three values — you'll paste them into AutoRFP's wizard in Part 4:

Before you verify the connection, assign at least yourself — and ideally a small pilot group — to the Enterprise Application. Entra only lets assigned users complete SAML sign-in.

Expected result: Your pilot users appear in the Users and groups list for the application.

Expected result: After signing in through the popup, the wizard shows a success state and advances to the Enforce step.

If Verify fails, the most common causes are:

Fix these before enforcing.

Expected result: You're signed out, and signing back in redirects you to Microsoft for authentication rather than showing an AutoRFP password field. This confirms enforcement succeeded.

The table below explains what changes for AutoRFP users once you enforce custom SAML SSO with Microsoft Entra ID.

Microsoft Entra ID lets users launch applications from the My Apps portal (myapps.microsoft.com) or from the Microsoft 365 app launcher. For most SAML applications, clicking the tile in My Apps triggers Entra to generate and send an IdP-initiated SAML response directly to the application — a response the application never asked for, as opposed to the normal flow where the application (the "service provider," or SP) requests it first.

AutoRFP's custom SAML connection is service-provider-initiated only: it expects to start every sign-in itself and does not accept an unsolicited, IdP-initiated SAML response. This means the default My Apps tile behavior for a SAML-mode Enterprise Application will not work for AutoRFP — clicking it is expected to produce an error rather than signing the user in.

To give users a working shortcut from My Apps, use Entra's Linked single sign-on mode instead of relying on the SAML app's own tile:

Expected result: Users see a working AutoRFP tile in My Apps. Clicking it opens the bookmark URL, which starts AutoRFP's own (service-provider-initiated) sign-in flow and redirects to Entra normally — this is functionally the same experience as a bookmark or favorite, not true federated single sign-on through Entra, but it gets users to the right starting point.

Linked mode does not perform authentication itself — Microsoft's own documentation describes it as "adding a link" rather than providing sign-on functionality — so the actual authentication still happens through the SAML Enterprise Application you configured in Part 2.

The table below lists SAML and SCIM problems administrators run into with Microsoft Entra ID and AutoRFP, and how to resolve each one.

Yes. The Enterprise Application you create for SAML sign-in does not support SCIM provisioning — opening Provisioning on that application returns an error stating that automatic provisioning isn't supported out of the box. Create a second, dedicated non-gallery Enterprise Application in Entra specifically for SCIM, and connect that one to AutoRFP's SCIM endpoint.

Custom SAML SSO on its own authenticates existing AutoRFP accounts by matching the email or UPN Entra asserts to an account's existing email — it does not create new AutoRFP accounts. A user without a matching AutoRFP account cannot sign in via SAML; you (or SCIM, if enabled) still need to create or invite that user in AutoRFP first. Existing roles and permissions in AutoRFP are unaffected by enabling SSO — roles are managed inside AutoRFP, not by the SAML connection.

No — there's no dedicated break-glass mechanism. Password-based login is disabled organization-wide once SSO is enforced, with no admin exception. If every administrator is ever locked out (for example, if Entra becomes unreachable), contact AutoRFP support directly — they can access and correct the account configuration on your behalf.

Sign-in fails for that user, even though they authenticated successfully in Entra — AutoRFP can't connect the asserted identity to an existing account. There is currently no self-service way for an administrator to edit a user's account email directly in AutoRFP. If a user's email changes in Entra (for example, during a company rename or domain migration) after SSO was enforced, contact AutoRFP support with a confirmed list of old and new email pairs; support can update the stored account email for you without the user losing access to their existing projects or content.

No. AutoRFP's SCIM implementation does not support role assignment or group resources. Group membership in Entra can control who is provisioned into AutoRFP as a user, but it cannot set what that user can do inside AutoRFP — roles are managed entirely within AutoRFP itself.

No. Turning on SCIM provisioning does not change or interrupt users who are already active in AutoRFP, and it does not affect invitations that are already pending. SCIM only manages account lifecycle going forward for the users you assign to the provisioning application.

This almost always comes down to one of two things: the affected users either aren't assigned to the Entra Enterprise Application, or the email/UPN Entra asserts for them doesn't match their AutoRFP account email. Check assignment first (Part 3), then check the claim mapping (Part 2, Step 4) for the affected users.

Because AutoRFP's SAML connection only accepts service-provider-initiated sign-in, but the default My Apps tile for a SAML-mode Enterprise Application sends an unsolicited, IdP-initiated SAML response. AutoRFP rejects that unsolicited response, so the tile shows an error instead of signing the user in. Use Entra's Linked sign-on mode with AutoRFP's bookmark sign-in URL instead — see "Microsoft Entra ID-Specific Capabilities" above.

Yes. An administrator can select Disable SSO from AutoRFP's Integrations settings at any time, which restores password-based sign-in for the organization. However, any user who signed in via SSO while it was active will need to reset their password before they can sign in with a password again — their old password does not automatically start working.

The table below is a quick reference for tracking a custom SAML SSO rollout with Microsoft Entra ID from start to finish.

💬 Live Chat: Available in-app — type "human" to reach the team directly.

📚 Learning Centre: learn.autorfp.ai/en