This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(51.2, 78%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDM%3C/text%3E%3C/svg%3E)
The Azure B2C user flow api in beta is only returning ElementType = UxElement. Is this expected or a bug?
Also, is there a timeline for when the B2C user flow work will be moved out of beta into a production version?
Hi @Davis, Michael , what are you querying to get that response? I'm a bit confused by what you mean. For example, somewhere in the flow when you hit submit are you getting a response that says "ElementType = UxElement?" Or when you try to find what "ElementType" is you're getting back "UxElement?"
As for the timeline, we have no updates at the moment.
Please let me know and I can help you further.
Thank you,
James
I did a bit more digging and noticed it's for custom languages.
For the sign in user flow, when you query for custom language en-US: beta/identity/b2cUserFlows/b2c_1_signin/languages/en-US/defaultPages/signin/$value
You only get objects in the LocalizationStrings list that are of ElementType = UxElement. There are only about 15 items in the LocalizationStrings list.
When you download the Sign In default localization strings directly from the azure portal for language en, you get objects in the LocalizationStrings list that are of ElementType = UxElement, but you also get objects that are of ElementType = ClaimType, ElementType = ClaimsProvider, ElementType = ErrorMessage, ElementType = InputValidation, and ElementType = Predicate. There are about 85 items in the LocalizationStrings list.
You can also only update ElementType = UxElement for custom languages, but can update all of the above ElementTypes for the required languages.
Is this discrepancy between localization strings for custom languages and required languages expected?