Thanks for raising this, Bryon Perona—you're right that the current flow is more disruptive than it should be. The reason it works this way today is rooted in how SSO interacts with user identity in the dashboard: once SSO is configured, the dashboard's own user provisioning is handled through your IdP, which means there's no eligible email/password account to transfer ownership to while SSO is active. That's why the documented workaround requires removing SSO first, transferring ownership, then re-enabling.

We hear you that this creates unnecessary interruption for other SSO users in the meantime. It's on our radar as a self-serve gap worth addressing—we'll update this post if the status changes.