We definitely recognize the popularity of this feature, and we discuss it constantly during the planning phases. However there are certain technical limitations in the system that add a large amount of development cost. Because of the cost and the fact that there is a workaround available, other features get prioritized over this one.
That being said, please keep voting for it. The popularity of the feature does help bring it up and makes us reconsider every time.
Apologies for the delay.
We’re doing some research both on the specifics of this ask as well as what it would take to support this.
Is the ask here to do the same thing that regular Azure AD does (see: https://blogs.technet.microsoft.com/enterprisemobility/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles/) or is are there different requirements around this for Azure AD B2C?
We continue evaluating several alternatives to provide full email customization. We are actively working on an alternative.
Unfortunately we do no yet have an ETA.
Dan: They are probably using custom policies.
You should watch this for inspiration and examples of what can be done with custom policies, and other videos in the same channel:
Good luck! (You will need it to, to keep track of all the lines of config in many files which is part of a policy :-)
I hope it will be possible to customize the "from" field in the emails, and some custom text content.
It would be great if this also can work for Azure AD B2C.
Thank you. We will examine the experience of duplicate sign ups across Identity providers. Would performing this check by using the email address be sufficient?
BTW, Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview…
We look forward to your feedback
Are there any news about the roadmap and the preview about this? This is a very important issue for us. Perhaps users can be allowed to merge accounts in case the email addresses are not the same?
Thanks for your suggestion.
The signup/singin policy does not automatically redirect to password update by design.
I’m leaving this item open though, to capture the ask to streamline this experience so as not to require the application to do this detection of the error code and subsequent redirection to the password reset policy.
I found a reference to the fact that clicking the "forgot password" link will POST a message into the client site which then needs to handle this and redirect to the desired policy (for example B2C_1_xxxxx_ResetPassword).
Take a look at the page referenced by the link below, and search for the error code "AADB2C90118":
I have this problem only for the Email attribute, the other ones seems to stay in the existing order. The Email attribute is jumping from the top to the bottom of the ordered list.
We have created samples to do this in custom policies here:
While we realize this is only works for custom policies (the part where you can track versions of consent), we currently don’t have plans to implement this in built in policies.
We’re working on an improved error controller that includes suggested remediations for errors. However, your client app should never change behavior based on specific error codes – these are internal and subject to change at any time.
Hi all, unfortunately we don’t have plans to share out a public roadmap. This is constantly changing as we’re listening to customer requests. We will continue to update feedback.azure items as they come up so feel free to suggest anything you are curious about.
Thanks for supporting this feature.
Great idea. Thanks for your suggestion.
Thanks for the suggestion.