While the Dynamics 365 Portal product offers flexibility in many areas, unfortunately the user registration process is not one of them. If you’re looking to add some fields to the form the user fills out when registering for your Portal, you’ll quickly find there is no simple way to do that. In this series, I’ll provide a different approach that might suit your needs if a custom user registration experience is required for your implementation.

The Out-of-the-box Registration Experience

The out-of-the-box experience revolves around creating a contact, without really any details associated with it. Whether you’re using local authentication or an external identity, all you really need to provide is an email address and your login info. Once logged in, you are redirected to your profile page, but there is no out-of-the-box way to enforce that someone fills out the rest of their profile before leaving that page.

There is no out-of-the-box way to customize the form that you see when registering – you can’t easily add fields to capture their name, address, etc. This means you could end up with a lot of blank contacts if users register but never fill out their profile.

Some Registration Options

Being able to customize the registration process is a question that comes up frequently on the Dynamics 365 Community Forums – and people have come up with some creative solutions.

Often the solutions involve using JavaScript to create additional fields on the out-of-the-box registration form. However, the challenge becomes how to save any data entered into those fields, because without additional code, the values in those fields will be ignored. Possible solutions I’ve seen are:

• Handling the onclick event of the Submit button, storing the values in local storage, and then using the values in local storage to prepopulate those fields on the profile form (the nice thing about the profile form is that it is customizable). This assumes that the person is going to click save on the profile form – if they don’t those values will never be saved to Dynamics.
• Using a hidden IFRAME that contains an Entity Form where you can pass the required information and use JavaScript to submit the form on the user’s behalf. I’m personally not a huge fan of this technique – the performance isn’t great and it just feels a bit hacky to me.
• Use a Companion App to save the data once the user has logged in. I don’t mind this technique, but adding the overhead of a Companion App just for this process might be a bit much.

Another option is to essentially hide all portal functionality until users fill out the required information. This can be done by waiting to assign Web Roles to users until after they’ve filled in those fields (and hiding all functionality behind a web role that isn’t just Authenticated Users). This is the technique employed by the out-of-the-box Partner Portal.

Or, if you’re going to go down the Companion App road, you can create the entire registration form from scratch. However, the challenge with this is properly handling the authentication pieces. If you’re using local authentication, there are some workflows that can help with properly setting the password for a user (also, keep in mind that local authentication is deprecated, so perhaps give Azure AD B2C a try). If you’re using an external identity provider, it may be possible to reverse engineer how to create the necessary records in Dynamics, but it can be a bit tricky, especially if it’s your first time.

I’m going to present another option here, and then in subsequent posts I’ll provide more details on how to make it work.

A Completely Configuration-Based Approach

The option I’m going to detail in this series requires no coding skills – it can be accomplished completely through configuration (although I might use a bit of code at the end to clean up a few experiences, but it’s not required to get it working). At a high level, the steps are:

1. Create a new custom entity that includes the fields you want to capture on the registration (except username and password). Let’s call it Portal User Registration.
2. Create a standard Entity Form that allows anonymous users to insert one of these records.
3. Use workflows to create a Contact record based on the submitted information, and then use the standard Invitation Code model to allow the contact to setup their authentication.

By following those steps, you can create your own custom registration form without writing a line of code. There are a few other benefits to this technique that I’ll also get into.