ENGINEERED CODE BLOG

Dynamics 365 Portal: Customizing Portal User Registration Process – Part 2

In my second post in this series on creating a custom registration form for a Dynamics 365 Portal implementation, I discuss the custom entity and tying it to an Entity Form (or even a Web Form!).

In my second post in this series on creating a custom registration form for a Dynamics 365 Portal implementation, I discuss the custom entity and tying it to an Entity Form (or even a Web Form!).

The Custom Portal User Registration Entity

The first step is to create a custom entity you can use to capture the fields you require. In my trivial example, I’m looking to capture the user’s first and last name, along with an email address plus the type of account that they want to sign up for (either Gold, Silver or Bronze). As mentioned previously those fields (except for email address) don’t appear on the out-of-the-box registration form, and there is no simple way to add them.

So, I’ve created a custom entity called Portal User Registration with those fields, like so:

What About Just Using Contact Instead of a Custom Entity?

You might be thinking to yourself, couldn’t I just create a form that allowed the user to directly create a contact, rather than creating this new entity type? Yes, you definitely could, and I don’t think that that is a bad idea. However, there are a couple reasons I like the custom entity:

  1. There may be fields you need to capture on the registration form but aren’t necessarily fields on the contact record. For example, your registration form may have account name, account address, etc. You can include all of these fields on your registration entity, and then use workflows (or Microsoft Flow) to create the proper entities.
  2. You may have fields that you need as part of the registration, but aren’t needed after that. In my trivial example, the type of account could be considered one of those fields. As you’ll see, I use that field to determine if the user gets an additional web role, however it’s not something I need to store on the contact record. Typically contact records are complicated enough – they don’t need extra fields unless they are necessary.
  3. This approach allows you to perform business logic on the record before creating a contact, perhaps business logic that may determine the user shouldn’t get an account. If this information is stored in a separate entity, you don’t have to worry about your Contacts table getting polluted with records that never turned into real Portal users.
  4. You’ll always have a history of what the user filled out when they first registered. Unlike the contact record, which can most likely change over time, the registration record is a snapshot of what they originally submitted.

Again, all that being said, I don’t think using Contact instead of a custom entity is necessarily a bad approach.

Creating the Entity Form

Next, we’ll create a simple Entity Form that allows for the insert of our custom entity. It really doesn’t get much simpler that this:

Make sure the Mode is Insert, and that Enable Entity Permissions is unchecked, as we want anonymous users to be able to create these records.

Finally, we’ll add the Entity Form to a Web Page – in my case I called it User Registration, and we’ll get the following:

With that in place, user can submit a registration via our Portal with our own custom fields.

What about a Web Form?

Perhaps your registration form is complicated – so complicated that it should be multiple steps. Does this technique work with a Web Form instead of an Entity Form? Definitely!

If you use a Web Form, you’ll have to modify when the workflow that we’ll setup in the next post triggers, as you won’t be able to trigger on the create of the record. However, other than that, everything else should be very similar.

I definitely recommend using a custom entity in this case (as opposed to using the Contact entity), as you are likely to get abandoned records from people who don’t complete the entire form, and you don’t want those in your Contact table.

In my next post, I’ll cover the behind the scenes processing that needs to happen to create the contact, and to allow the user to associate their contact with login credentials.

Dynamics 365 Portal: Customizing Portal User Registration Process

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.

Continue reading “Dynamics 365 Portal: Customizing Portal User Registration Process”

Dynamics 365 Portal: Self-service Diagnostics with the Portal Checker

In case you haven’t been able to tell, I’ve been on a bit of a Dynamics 365 Portal performance kick these days. One tool I didn’t include in my post on where to look when things are slow was the Portal Checker, which provides a self-service way to identify potential issues with your Portal, with suggestions on how to solve them.

Continue reading “Dynamics 365 Portal: Self-service Diagnostics with the Portal Checker”

Dynamics 365 Portal: Where to Look When Things Are Slow

It seems to be happening more and more these days that we are being asked to assist organizations that have launched a Dynamics 365 Portal but they are unhappy with the performance. If you find yourself dealing with a portal that is slower than you think it should be, this post should give you an idea of where to start looking.

Continue reading “Dynamics 365 Portal: Where to Look When Things Are Slow”

Dynamics 365 Portal: Custom Server-side Code with a Companion App

I spent last week in Amsterdam attending both eXtreme365 and the User Group Summit, and was lucky enough to get to present three sessions on Dynamics 365 Portal topics. At each one of these sessions, one of the areas that generates the most interest is when I discuss the idea of a Companion App. Companion Apps are a technique you can use to leverage server-side code in your Portal implementation, and since it’s a topic I haven’t really covered on my blog, I thought it was about time.

Continue reading “Dynamics 365 Portal: Custom Server-side Code with a Companion App”

A Brief History of Microsoft Dynamics 365 Portal: Where We’ve Been, and Where We’re Going

My latest article for MSDynamicsWorld.com was published today. Coming up on the three year anniversary of the first release of Microsoft’s Dynamics 365 Portal, I thought it was an appropriate time to review the history, from its inception as Adxstudio Portals, to the acquisition, to where the platform has come, and is going, under the direction of Microsoft.

Continue reading “A Brief History of Microsoft Dynamics 365 Portal: Where We’ve Been, and Where We’re Going”

Contact

Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.