Feature Request

Our company utilizes Single Sign-On (SSO) via Microsoft 365 to login to our Doc360 accounts. We have a security policy which prevents permanent cookies in our browser, so I periodically need to re-authenticate into our tools, including Doc360. A recent Doc360 UI update presented two new buttons to click for login: Google Workspace and Microsoft. While I previously used the SSO-specific button, I assumed that the Microsoft button would still prompt SSO, since my same business account is logged into the browser already. However, I was met with what appears to be a completely standalone Doc360 session where I was prompted to create a new Project. There was no option to log out of the session to return and use SSO properly, and clearing my cookies did not change the session. I was required to actually create a dummy project in order to properly log out and correct my login. My desired fix is simple: If a user clicks on either the Google Workspace or Microsoft buttons during login, the system will first check to see if SSO is enabled with that email account and with the selected platform. If SSO is detected, it will instead proceed with the SSO login as if you clicked the SSO button directly. If SSO is not detected, it would continue normally with a fresh account. This may not be feasible to resolve, so an alternative would be to allow the user to fully log out of the session prior to creating a project so that the dummy project is not needed in order to fix the login session.

A project can have Self-Registration and SSO with Auto-assign enabled at the same time, even when Auto-assign already serves the need Self-Registration is meant to cover, resulting in overlapping and potentially confusing authentication configurations. Suggested enhancement: Add a configuration-time warning when Self-Registration is enabled on a project that also has SSO with Auto-assign active, prompting confirmation that the overlap is intentional. Benefit: Reduces the chance of unintentionally exposing an extra sign-up path and makes it easier to audit and reason about a project's authentication configuration.

Problem Statement: Because the assignment step happens entirely in the IdP, Document360 project Owners/Admins currently have no visibility from within Document360 into which users are attempting (and failing) to log in due to missing IdP application assignment. Admins typically only learn about this when a user reports it manually. Suggested Enhancement: Consider a login-failure log or notification (visible to project Owners/Admins in Users & permissions settings) that flags failed SSO login attempts along with the reason where determinable (e.g., "user not assigned to application"), so admins can proactively resolve access issues. Customer Benefit: Faster detection and resolution of access issues for SSO users, less reliance on end users to report and describe cryptic IdP error messages.

Problem Statement: The "not assigned access" error is generated and displayed by the Identity Provider (IdP), not by Document360, so the end user sees only the IdP's raw error text with no indication of what caused it or who can fix it. Since the fix (assigning the user/group in the IdP) can only be performed by the customer's IdP admin, end users receiving this error currently have no way to know that Document360 support cannot resolve it and that they need to contact their own organization's IdP administrator. Suggested Enhancement: Where technically feasible, add a Document360-branded interstitial or a "Need help signing in?" link on the redirect/landing experience for SSO failures, pointing affected users to the relevant troubleshooting article and clarifying that this class of error must be resolved by their organization's IdP admin, not by Document360 support. Customer Benefit: Reduces support tickets raised against Document360 for an issue that Document360 cannot fix, and gets end users to the right internal contact (their own IT/IdP admin) faster.