ReadyXRM

Both the Dynamics 365 Online Portal and Adxstudio Portal have the ability to allow visitors to register to give them access to authenticated areas of your site.  Despite what authentication method you use (Forms based, Windows Live ID, Active Directory, Google, etc) the portal will create a corresponding CRM contact record for each visitor that registers.

You can then provide your contacts with additional web roles and entity permissions to provide them access to certain areas of your site and access to certain data.  You can also configure entity lists to be filtered based on the current logged in user, so you can show them data based on who they are. (e.g. showing a list of Invoices for the contact that is visiting the portal)

If your Dynamics 365/CRM system has been in use for a long time, or you are migrating legacy data to Dynamics 365 and are setting up a new portal, you ideally don’t want all your existing portal contacts to visit the portal and register a new contact.  This would result in a duplication nightmare and the portal contacts also might not get visibility to thier related data that you might have stored in your CRM system.

Microsoft has addressed this issue by giving you a mechanism to send out invite codes to your existing contacts.  Click here to the online instructions to setup an email template and run a workflow to send an email to your existing contacts.

This very question came up during one of our requirements gathering sessions for a client that was migrating from a legacy Siebel system to Dynamics 365.  When we discuss requirements, we also ask about data volumes as these can affect some of the design decisions for an XRM project.  This particular client was migrating over 6 million contacts that spanned many years of transactions.  The organization provides training and certification and had to maintain this data.  They had class registration, invoice and certification records for their contacts and ideally wanted to provide visibility to this data on the portal for contacts who wanted it.

Creating a workflow to send out 6 million emails was out of the question.  We also didn’t want them to create brand new portal contacts, as they would not have visibility to any of their historical data.

For starters, many of these contacts didn’t have email addresses (as email wasn’t even a thing when they were added to the legacy database) as well as many of the ones that did likely would have changed or updated their email address and despite best efforts, many of these contacts would have gone stale, were already duplicated (in some cases dozens of times) in the system or really didn’t need or want to access their data on a portal.

The solution we came up with was more of a “opt-in” process.  We designed the portal such that we would ask a visitor if they had done business with the organization previously and they could then enter in their email address, and only then would we send them an invite code where they could establish their portal access and see their legacy information.

I created an email-enabled entity called “Invitation Code Request”.  I needed it to be email enabled so we could send emails out of Dyn365 to the email address specified on the record.  The entity also had a lookup to the contact for which it may eventually be associated, an invite result (see below) and also a language field (Canada has 2 official languages).

I also created an portal page with an entity form linked to the invite code request entity that was available on the public web site, the page just asked the user for their email address.

In CRM, we wrote a plug-in (but a North52 formula would work very well for this too*) that would search the contact database and try to match the email address.

If there was no match, it would flag the record and we would email the requester (that is why I had to make the entity email enabled) back with messaging saying there was no match, so try an alternate email or just sign up for a new portal account.

If there was a unique match, again flag the record and the system would generate a portal invite code to the related contact and email them that code with a hyperlink to the OOB registration page.

By entering in the invitation code, the legacy contact would then have access to the portal.

If there were multiple matches, record was flagged and the system would route this to internal staff member that would need to merge the contacts and send out an invite manually, or directly contact the person to sort it out.

We obviously did not get 6 million contacts registering on the portal, but with this method, a few thousand existing contacts were able to gain access to the portal (that actually wanted access) and view their historical class registration and certification information.

This solution again highlights the flexibility of the Dynamics 365 and Portal platform for solving complex business requirements.

*Special thanks to Bruce Buxton of North52 for asking me a simple question that resulted in a lengthy email describing this particular solution which converted nicely into this blog posting.  If you do any kind of Dynamics 365 configuration, you need to use North52!

I hope you found today’s post helpful and enlightening.

Cheers
Nick