I worked around that by deleting the just created account on the action the problem is that it does not redirect to the sign up screen with an error.
+1
Our main use case is: “Deny a social registration if a user with the same email address already exists. (i.e. enforce unique email addresses)”
Currently this is implemented with a hacky and overly complex post-login Action (which doesn’t fully work due to another issue.
Enforcing email uniqueness would be less of an issue, if the official account linking extension would support Actions: Allow for account linking with actions - Auth0 Community
I understand that the Auth0 team has their own roadmap and priorities. But it is a bit frustrating that there is no activity for months/years on valid and useful requests from the community.
+1 for this
We have an usecase in an organizational context. We want to reject user-creation when the user tries to log in the first time via enterprise-connection and the related licence is not sufficient.
Current workaround would be to reject login and delete the just created account in the postlogin-action as described by @carlos.trujillo . This feels hacky 
1 Like
@konrad.sopala any update here from the product team?
1 Like
Hey there @j.krabs !
Let me follow up with the engineering team on that front and get back to you shortly!
2 Likes
Any updates from the engineering team?
Not yet but I think we can expect the answer in the coming days. Will share it with you once I have it
Just got an update from the team.
Work on the user management action triggers is on the roadmap for this year and supporting pre/post creation triggers for social connection will be evaluated and included if possible.
2 Likes
Hi All. I’m also facing the same issue. Pre User Registration is not event triggered. I want to disable social connection Sign Up
please also consider enterprise connections and not only social connections 
The whole concept of pre-registration Action without ability to control other providers is meaningless.
the reason mentioned here about the fact that the user is known only when returning back from the social provider is just not enough - i don’t see a reason to call the action just before creating the user entity. (there might be different signiture to the action method though)
Another +1 here for triggering pre-user registration for all types. It’s an incredibly hamstrung feature without this.
Our desired use case is to force users into the Home Realm Discovery flow (to use SSO) if their email domain satisfies a criteria. Currently, users can (and will) click the “Login with Google” button instead of entering their email to trigger home realm discovery. This results in an account being created that is e.g. not managed by the customers Okta instance, but instead by their G-Suite instance, adding complexity to access revocation flows.
An alternative workaround that Auth0 could build, albeit less elegant, might include allowing us to only show social login buttons AFTER potential home realm discovery has occurred. As it stands today, the social buttons are available from step 1 of the universal login flow.
Just running into this issue myself. It seems like you thought this might be addressed this year; not much of the year left, hoping it might happen soon?