In my third post in this series on creating a custom registration form for a Dynamics 365 Portal implementation, I discuss the behind the scenes processing required to get the registered user a contact record with login credentials.
In my previous post I created a custom entity called Portal User Registration, along with a Dynamics 365 Portal Entity Form that allows users to submit their registration. Once they fill out that form, a record is created in Dynamics 365 – however that form does not ask for any authentication credentials, and it creates a custom entity, while we all know that users require a Contact record in order to be able to login to a Portal. We’ll solve both of these using a combination of the out-of-the-box Invitation Code Model and workflows.
The invitation code model is used to allow existing contact records to be associated with Dynamics 365 Portal login credentials. The process is essentially the same, regardless of if you’re using local authentication or an external identity provider like Azure AD B2C. It works like this:
Invitation Codes are often used for new Portal implementations that already have a large number of existing contacts in Dynamics 365. It allows you to invite your existing contacts to the system, as opposed to them having to register, which will lead to duplicate contacts. However, there is no reason we can’t use this model for new registration as well!
We’re going to create a workflow that fires on the create of our custom Portal User Registration entity, and performs the following tasks:
As a bonus, I’ve added one extra feature, and that is to take into account the Type the user selected when they submitted the form. If they selected Gold my workflow will use the Portals:Assign Web Role Custom Workflow Activity to assign the Gold Web Role I created. This is a simple example, but there are a lot of things you can do in these workflows if your registrations process is complex.
The completed workflow looks like:
When using the Invitation Code model, you’ll need to customize Send Invitation workflow to ensure that the email is coming from an appropriate user (so that the email will actually go out), that the messaging updated, and that the URL is updated to point to your Portal.
Could you use Microsoft Flow instead of the traditional workflows? Probably. However, we’re using some of the out-of-the-box invitation code workflows, which could probably be rewritten in Microsoft Flow, but for the purpose of this series, we have not.
Now that we’ve got our workflow setup, a user can register on our Portal using the custom registration form. Once they submit, they will receive an email inviting them to our Portal. After clicking on the link, the user will be presented will the opportunity to configure their authentication using any of the enabled options. After that, the user will be logged in and successfully joined up with the contact containing the information supplied in the initial form submission.
In the next/final post, I’ll touch on some items that can be adjusted to improve the user experience.