The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
See the Problem Solver of the Month for DecemberCongratulations to Ievgen Miroshnikov for be selected in a random drawing on Jan. 2 for in our monthly Dynamics 365 Community Problem Solver Sweepstakes.
Read aboug Ievgen | Learn how to enter
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
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 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:
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:
Again, all that being said, I don’t think using Contact instead of a custom entity is necessarily a bad approach.
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.
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.
The post Dynamics 365 Portal: Customizing Portal User Registration Process – Part 2 appeared first on Engineered Code.
Business Applications communities