SSO and Non-SSO Users should be treated as a unified entity
Krishna M
I have a lot of Team Accounts and Readers within my project and I prefer that they access the documentation exclusively through SSO. However, in the event of an outage, they should also have the ability to log in via the general Document360 login. In such cases, I would need to either add another account as a standard user or enable self-registration.
In this scenario, I expect my team members and readers to be consolidated under a single account. However, Document360 currently treats them as separate accounts, which impacts various areas, including analytics and granular access management.
Therefore, we request that both standard login users and SSO users be mapped under the same account, treating them as a unified entity. The same approach should apply to readers.
Implementing this change would avoid confusion and significantly reduce the manual work from an administrator's perspective.
Log In
Bob Dzimbowski
This undermines the whole idea of the SSO security concept. Just how many outages do you have to want to go down that rabbit hole?
Ramesh Lokesh
Currently, if a user is associated with an SSO account in their Document360 project, they can register for a new trial project, as SSO and standard Document360 user accounts are treated as separate on our end (even if the email addresses are the same).
This situation is not ideal. If a user is already associated with a Document360 project—whether as an SSO or non-SSO user—they should not be permitted to sign up for a new Document360 trial project.