In the summer when I did a series of posts on one way of customizing the registration process for Portal users, Dileep Singh (@rulesrchanged) – the head of Power Apps Portals at Microsoft – reminded everyone not to forget about how you can customize the registration experience if you’re using Azure AD B2C. In this post, I’ll go through the steps to do just that.

What is Azure AD B2C?

If you didn’t catch my last post on Azure AD B2C, I’d recommend checking it out to get a background on the technology. At a high level, Azure AD B2C is an identity provider in which you can configure other identity providers. So, you can configure your app (or in this case, your Portal) with a single identity provider (Azure AD B2C), yet still support logging in with different types of accounts like Facebook, Twitter and LinkedIn.

Customizing the Registration Screen

The common request we get when setting up a Portal is to customize the fields that appear when new users are registering for a Portal. The out-of-the-box registration form for Local Authentication looks something like this:

As you can see, all we need to provide is email address, username (if not using email address), and the password. In the case of external identities, we don’t even necessarily get email address (although it is required right after you log in). There are no fields for first or last name, company, phone number, etc. As I said, often organizations want this type of information captured as part of the registration process. The typical flow has newly registered contact directed to the profile form, with the hope that they then complete their profile, but for many organizations they feel this is too late in the process.

Unfortunately, there aren’t any easy ways to add fields to the registration screen. It is not an Entity Form that can be changed via configuration. Your only real option to customize that screen is to use JavaScript to add new fields to the form, and then come up with a way to get that data saved back to CDS (I’ve seen it done via a Companion App, or even by persisting it in browser storage until after the registration is complete and then using that information to prefill the profile form). I wouldn’t describe any of the solutions I’ve seen as elegant. That’s one of the reasons I published the series mentioned in the intro, as an alternative approach. And based on Dileep’s comment, I’d like to describe another technique that leverages Azure AD B2C.

How Does an Identity Provider Help With Registration on a Power Apps Portal?

Azure AD B2C has the concept of User attributes that can be configured to be required as part of the registration process. When using Local accounts, these fields appear directly on the sign up page. When using social accounts (like Facebook, Twitter or LinkedIn), these fields are displayed after the user logs into those accounts. Azure AD B2C has a number of built-in User attributes, and also supports creating custom attributes. The great news is that using these User attributes in combination with a much more configurable sign up page means you have a lot more control over the registration process.

The steps to do this are:

1. Configure your Portal with Azure AD B2C. See my previous post, or better yet, see these step by step instructions from MVP Nick Doelman (@readyxrm).
2. Use out-of-the-box or create custom User attributes for the fields you want to capture on the registration form – see this (somewhat dated) documentation.
3. In your Sign up and sign in User flow, enable your User attributes so they appear on the sign up form, and also include them in the Application claims.
4. [Optional] Customize the look and feel of your sign up page as per this documentation. You can customize the look and feel of you sign in page, as well as the sign up pages for both local accounts and social accounts.
5. Configure Power Apps Portals Claims to support sign-up scenarios as per this documentation. This will make the Portal read the claims from the token and set the values on the Contact record. For example, in my testing I used a Site Setting value of jobtitle=extension_customjobtitle – note that my custom field name was just customjobtitle – the extension_ was added automatically within the name of the claim.

Now, when users register for your Portal, they’ll go through the registration process in Azure AD B2C, which will capture the User attributes (whether they are out-of-the-box or custom), which will be included as claims in the token sent to your Portal, and the Portal will use those claims to set values on the Contact record it creates. You’ve now got a registration process for your Power Apps Portals that captures the profile information you need!