How to enforce confirmation of email before enabling Portal functionality

A common requirement I’ve come across is the requirement to force user to confirm their email before accessing Portal Functionality.  Out of the box, users can simply sign up and away they go – they are taken to their profile and can then browse about the website. Now, most people implementing portals have some understanding of Web Roles and Web Permissions, but the confusion is how to tie those permissions to the confirmation of the email – and how to improve the sign up experience to make the whole thing more seamless.

There’s two basic approaches. The first is to use the out-of-the-box Portal sign up experience and then Assign the correct Web Role(s) to users only once they have used the (out-of-the-box) email confirmation function. (You can learn more about creating web roles here: https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/create-web-roles/) 

The second approach is to turn off open registration and make your Portal Invite-Only. (Learn about invitations here: https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/invite-contacts ). This might not sound like the desired path if you want users to be able to freely sign up, but don’t worry – we will let them up, we just need to create a custom signup form (which is just an entity form that create a contact: https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/entity-forms ) and then configure a workflow to send the invite to anyone who signs up. This method will allow you to have the more typical web experience because you need to confirm your email first, before you even land on the profile screen.

Let’s look at both of these methods.

Using OOTB Registration

This is the easiest method to configure. Using the default registration method, when open signup is enabled (which is the default setting) users can sign up freely by clicking “Sign In” on the header, which will take them to the authentication page, from where they can click Register.

They will authenticate using B2C or (will pick a username and password if you are using local forms-based auth) and then will immediately be authenticated and taken to their profile.

Once we are on the Profile Page, we’ll be prompted to enter in our contact info, which is blank in the system at this point. One thing to note, is that at this point, a stub contact record has indeed been created within the database, with a blank First Name and Last Name.  We also have the default authenticated web role, so we are free to navigate away from this page provided that other parts of the portal are not locked down by web page access control rules. This in and of itself might disqualify this path depending on your exact requirements, and if it does, check out the second method (configuring a custom signup form).

We’ll want to lock down any portions of the site that require email confirmation using Web Page Access Control Rules (link to MSDN documentation). The rules will be of type restrict read, which will prevent access to any pages covered by the rule, except for users in a Web Role related to the rule.

This means, of course, that you will be creating a new Web Role as well.  You can call it something like “Confirmed Email Users”. This role will be given these restrict read rules (which will lock down the pages for everyone else).

You could for example, just have one or more members-only sections of the site, each with a parent page that you lock down with a Restrict Read Rule, or you could lock down the home page with a restrict read rule, so if anyone navigates to your site, they will immediately be taken to the sign in page.

Note however, that if you do this, you will then need to make sure that the default authenticated users role has access to the profile page, or new users won’t be able to go through the process. Remember that any more-specific rules will take priority over less specific ones, so if you put a restrict read rule on the homepage and relate it to your “Confirmed Email Users” role, you can override this by adding a restrict read rule to the profile page and assigning it to the default authenticated users role. That said, it’s probably best not to lock down the home page but to lock down the various pages in your portal providing the functions you want them to confirm their email for.

The missing part of the puzzle is of course how to assign the Web Role to newly registered portal users once and only once they have confirmed their email. To do this, you can create a traditional workflow to assign the web role to the user. This workflow will be triggered on  update of any contact record’s “email confirmed” boolean value to true. This boolean value is set when the user confirms their email. When the Value changes, the workflow will fire and associate the Web Role to the contact.

First, create the workflow (remember that this is a classic background workflow, and you might need to use classic mode in order to create new workflows):

Set the condition:

Assign the Web Role. For this you will be using an OOTB custom workflow activity step

Save and Activate the workflow. When users sign up, they will be taken to the profile and will see this message:

Clicking a link will send them an email which they can use to confirm their email, which will trigger the workflow and assign them the web role, granting access.

Using Custom Registration

One downside of the OOTB registration method I described above is that it allows people to authenticate, choose a username and password, and fill in their profile before ever confirming their email.  A common sticking point for client is that they wish users to be able to do none of these things until they’ve confirmed their email.  They want a registration form to be filled out, and once the form is submitted, the portal user will need to check their email for a confirmation email before they can fully authenticate to the Portal.

Fortunately, this scenario is easy to configure. A custom registration form will need to be used, which will trigger an email to be sent to the user. This email acts as an invitation to authenticate, and lucky for us there is an invitation model built-in to Portals that we can leverage for this purpose. We of course also want to turn off the default open signup mechanism – we only want users to register using our custom form. Once you’ve set it up, you can lock down the portal using the default authenticated users role and won’t need to create a special web role like you did with the first method – users can’t authenticate at all until they have confirmed their email via invitation.

The first step is to configure Portal security to be invite-only. Observe the following Site Settings: (https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/set-authentication-identity#enable-or-disable-user-registration).

Set “Authentication/Registration/OpenRegistrationEnabled” to false.

Set “Authentication/Registration/InvitationEnabled” to true.

This will have the effect of turning off the ability for portal Users to register using the OOTB registration – although you will build out a custom registration form to allow it. When they submit the form, they will receive an invitation email.

The next step is to create our registration form.  We will need to create an entity form (https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/entity-forms) with the following fields:

  • Name: Anything you want, I suggest “Register Contact”
  • Entity Name: contact
  • Form Name: “Contact Web Form” if this form exists, can be used, or you can create a custom form for use with this entity form.
  • Mode: Insert
  • Website: Your Website

That’s it.  Once you have created the Form, you’ll need to add it to a Web Page.  I recommend creating a page called “Register” and adding the form to that page.

Add a link to this page to the header of your portal, so you can always click there as opposed to the sign in page.  Make sure that when using custom registration that you don’t lock down the home page, because if you do, users will be sent straight to the OOTB sign in page, which can’t be customized.

Again, we need for an invitation to be sent upon submission of this form. To do this, we can again create a traditional workflow to send the invite to the user, and to set the value of the “confirmed email” boolean field on the contact record to true (so they won’t see the message prompting them to confirm their email in their profile).

The workflow will be triggered upon create of a contact record.

We can create a new workflow that uses a flag on the contact record to indicate that the contact was created on the Portal, so invitations won’t get sent to contacts automatically whenever a contact is created in the backend.  We can of course manually send invitations still, so that resolves the case of needing to send an invite to a contact that was created manually. Alternatively, we can just call the OOTB Send portal invitation to Contact workflow which does everything we need.

This workflow is OOTB and will create the invitation and send it for you:

The only thing we really need to add to the parent workflow, therefore, other than the fact that it triggers on create of a contact (and we can optionally check a flag to ensure it comes from the portal – i haven’t done that in my screenshots) is we need to set the email confirmed flag to true.  Since the process of signing up now essentially confirms their email, no need for them to do it a second time.

Once you activate the workflow, you should be good to go! Finally, a registration process that actually gives you what you would except in terms of UX, and fulfills the requirement to not allow activity on the portal until email is confirmed, to boot!

Hopefully this was useful to at least a few people out there.  I’ve seen this come up so many times I’m surprised it’s not an OOTB option by now. I hope you enjoyed reading and expect more posts soon! Be sure to like and subscribe!

How Portals fit into the Power Platform

Ah Portals, our favorite child of Microsoft Dynamics CRM. It’s been around for while and people have gotten used to it as a piece of the D365 picture. However, people are starting to pick up on the fact that the Power Platform has a Portal offering too? Is this the same thing? How do Portals fit into the picture of Power BI, Power Automate, and Power Apps?

Portals and Customer Engagement

Well I suppose the first thing to clear up is how Portals fit into Dynamics 365 Customer Engagement. And to do that, we need to clear up how Dynamics 365 Customer Engagement fits into Dynamics 365.

Well for starters, it’s not Dynamics 365 Customer Engagement anymore. With that out of the way, I’ve got nothing better to call the set of model-driven power apps that are part of the Microsoft Dynamics 365 licensing structure, so to heck with it, I’m going to keep referring to it as CE for this article.

It’s a long story, but the short-short version is that when CRM, NAV and AX all went online, Microsoft decided to market them all as the same thing – just different parts of the same platform. This actually makes perfect sense because in theory they compliment each other very well. NAV / AX (Now Business Central and F&O) handle the accounting / ERP side of things, which allow your business to manage its finances and inventory, while CE handles the sales and customer service side of things. Together they really do represent a complete picture, in theory, if only they integrated together a bit better.

So where does the portal come into play? Essentially, it’s the customer-facing portion of your customer engagement solution. Basically, if you are a business, and you have customers, you need a portal of some kind, and if you have a Dynamics 365 CE implementation, the Dynamics Portal makes a pretty good use case to fill this role. External users interact with your Portal which in turn interfaces with D365 CE.

Here’s how portals fit into D365

OK, but what does this have to do with the Power Platform?

So far we’ve been talking about D365 and how the Dynamics Portal fits into CE. However this article is about how the Portal fits into the Power Platform. So perhaps we should be asking ourselves how D365 CE fits into the Power Platform.

Well, it’s a long story. Really I would say that the best explanation ever was provided by MVP Nick Doelman in this blog post. Give it a read – it’s a great story.

Dynamics 365 and the Power Platform

Here’s the short version: Microsoft loves bundling software together into Platforms, and three applications that worked pretty well together were Power BI, Flow, and PowerApps (Now called “Power Apps”, with a space). Power BI is Microsoft’s premiere business intelligence software – it can connect to various data sources, create reports based on that data, and allows for powerful visualizations, data manipulation and forecasting. Flow (Now called Power Automate, in case you missed it) is a next-generation low/no-code workflow engine, also connecting to a variety of data sources and allowing for the automation (power automation!) and streamlining of repetitive tasks. Finally, PowerApps started as a platform to allow customers to easily build unique purpose-driven applications. This would allow “citizen developers” to build custom applications low/no-code. This began with a set of drag-and-drop tools and low-code functions to build pixel-perfect apps that connect with a large variety of different data sources via connectors.

As this was all coming together into the Power Platform, Microsoft realized that what’s missing from this combo of Flow, Canvas PowerApps, and PowerBI is a citizen developer-friendly data store that is easy to set up and customize. A highly extendable relational database -which could be called the Common Data Service (CDS) and a basic schema with some pre-defined entities like contacts, accounts, and activities – which could be called the Common Data Model (CDM).

Sound familiar?

Turns out Microsoft basically already had such a thing and that was the Dynamics CRM data model and business application layer. For years and years, we in the Dynamics CRM world had learned to adopt the “xRM” mindset and think of CRM as a platform, because of how extendable and robust it is. Dynamics CRM had in fact everything Microsoft was looking for in and therefore CRM formed the basis for this new CDS and CDM. In the spirit of not fixing what isn’t broken, the Unified Client Interface (UCI) was welcomed with open arms and the concept of Model-Driven Apps was born.

The Microsoft Power Platform | workingondata

The Dynamics data model was re-branded CDM and the different customization tools like the solution editor had a PowerApps (later “Power Apps”) label put on them. The power platform was really ramping up now – a complete platform allowing for all aspects of engagement, functionality, analysis, and automation to come together. What had been the “naked” CRM business application layer had become CDS/CDM. the customization tools and UCI came to form Model-driven Apps. The original pixel-perfect apps and tools because known as “Canvas” apps, and then Flow was renamed Power Automate for some reason.

But exactly where does “Dynamics 365” fit in? Is Dynamics 365 gone now? Or is it just ERP now? after all, CRM is just CDS/CDM and Model-driven apps now. The answer lies in the question of what apps we are talking about. The “CRM” part of Dynamics 365 – D365 CE – is no longer a platform, instead, it’s just a brand name (and licensing structure) for a series of first-party Model-Driven apps, that come pre-loaded with all sorts of features and functions that you can’t get otherwise. It’s still very much built on the Common Data Model and very much part of the Power Platform… Although it’s also still very much part of Dynamics 365 as well, so it’s marketed alongside the ERP side of Dynamics, as if things weren’t confusing enough. Maybe a diagram will help.

Dynamics 365 and the Power Platform

Portals and the Power Platform

This brings us back to the Portal. A while back I posted about how finally we get a “blank” Portal that runs off of CDS without needing Dynamics 365 licensing. This is brand new app type, right along Model-Driven and Canvas, known as Portal Apps. The Portal App is identical tech-wise to the Dynamics 365 Portal that we kicked this article off with. Just as Dynamics 365 apps are just first-party model-driven apps that come pre-loaded with features, so are the Dynamics 365 Portal Apps (like the Community Portal, Partner portal, etc.) first-party Portal Apps that use the Dynamics 365 licensing instead of the Power Apps licensing. Or to put it another way, just as CDM + Model-driven apps is a “naked” CRM, so are the Portal Apps, “naked” portals!

So what business value do the Portal Apps add to the Power Platform? Well, just as the portal represented the external “Customer” side of Dynamics Customer Engagement, the Portal Apps allow for external users to interact with your custom line-of-business application. The scenarios are endless just as are the scenarios for Power Apps – the limit is your imagination. Online shopping, profile registrations, service requests, open information, the list goes on – if you are building a line-of-business application with Power Apps and need a way to expose information to or capture interactions or information from external users, Portals is a potential solution.

Thanks for reading! Be sure to like, share and subscribe if you want to see more!

Portals have come a long way since Adxstudio’s xRM Framework

In case you haven’t heard, the Microsoft October 2019 Release plan has some pretty huge news when it comes to Portals – They are going to be put on center stage as a first-class app type along with Canvas Apps and Model-Driven Apps.

Starting soon, when you go to web.powerapps.com and go to create a new app, in addition to Model-driven apps and Canvas apps there will be a third type of app: Portal!

These Portals will be exactly the same as the previous portals, but you don’t need dynamics CE anymore. These Portals run off of the Common Data Model (just like before, really). In fact, you’ve been able to see the CDS portal in action for a while now. Now, Dynamics CE is still an important vertical to consider, so in a future post we’ll look at when you should skip CE and when you should still include it in your solution.

Portals are going to now be open to a much bigger audience as people jump onboard the power platform. With PowerApps, you can built out purpose-driven applications to suit your business needs – no longer are we modifying a CRM system to implement a system that doesn’t really have anything to do with CRM. Naturally, Portals are a key part of that story and the technology used to build Dynamics portals is being brought forward as the missing part of the puzzle. This feels so rewarding as all the work that my colleagues and I did at Adxstudio back in Regina, Saskatchewan at the old park street office building Portals has really come to full fruition.

Let’s rewind to 2009. I had just completed my Master’s Degree – well, scratch that – I was close to completing my degree and decided to start working full-time while I finished up the last “month or two” of my thesis. Actually finishing and defending my thesis would take well over an additional year, but that’s another story.

You see, I had accepted a fantastic offer for a brand-new developer from a local company in Regina, SK called Adxstudio. I started off right out of the Gate as a Developer on the Product Team working on little product called the xRM framework, which was nearing completion of version 2.2 when I came on board.

Most of Adxstudio’s business came via it’s other product, a Content Management System (which was a big deal at the time) simply called Adxstudio CMS. It was a fine piece of software, but most of our investment was in Microsoft Dynamics CRM, which had recently released version 4. We believed that Microsoft Dynamics was the future – and we were all in. What we had developed was a framework which allowed developers to interface easily with Dynamics CRM without interfacing with the SQL database directly. The primary use case for this was to integrate a website withe Dynamics 365, so that records such as contacts from CRM could be surfaced in some way on the website. Sound familiar?

Included was an authentication model that allowed you to log in and have your user associated to a Contact in CRM. It also had a fully functional CMS allowing you to manage the website via Web pages, Web Links, Content Snippets and so on. We developed a few different websites too – we didn’t call them portals yet – such as the Company Website, branded Wireframe Industries – boy I wish screenshots from back then survived – the Conference Website, which used the amazing technology of Silverlight, and Community Website, which added some baked in features such as Blogs, Ideas and Forums.

Well as Dynamics CRM 2011 came out the door, we made the decision to give the xRM framework base code to Microsoft. It became part of the official Microsoft CRM SDK. This was rewarding it it’s own way but put us at an advantage because now the best way to surface data from CRM onto a website was to use a Portal using our framework. You could do some basic stuff for free using Microsoft’s accelerator portals, or starting from scratch using the framework that came with the SDK, but if you really wanted to play with power, you could use our product, which we kept adding features such as Web Forms, and later Entity Forms, Entity Lists, and finally Entity Permissions to. This product was finally named Adxstudio Portals (v4 of the xRM framework).

As Dynamics went through releases over the years so did Portals. With version 5 the solution layering was completely redone from scratch – manually, by me at first (!) – while we refined our ALM processes (and eventually came out with a great toolkit called the ALM toolkit to help automate the process ). With version 6 the front-end was completely redone to use bootstrap and Entity Permissions were added. With Version 7, we added liquid support which radically changed how customization of the Portals was done. It was now ready for the cloud.

And with that, Microsoft announced the acquisition of Portals (and the Adxstudio brand). I had the privilege of working with their new Portal product team to help integrate the Portals into their product lineup. Version 8 of Portals, as we called it internally, would soon be released as Dynamics portals – a fully in-the-cloud solution that extended Dynamics 365 for Customer Engagement.

Fast forward to today, and finally we are able to do the things with Portals that we saw ourselves doing with it way back in the days were we used “xRM” as a buzzword. I can’t wait to work on many more Portals implementations and I’m interested to see where we go from here.

Thanks for reading.

A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard

In my post about the Create Portal Content Wizard, I talked about how easy it is to add content to the portal using point-and-click configuration, and demonstrated that the Wizard creates a whole lot of records in the background for you so that you don’t have to. It’s like magic! It certainly does beat having to spend the time configuring Entity Forms, Lists, Permissions, and web pages all from scratch. However, the Wizard also has its limitations. There are several scenarios that it simply can’t manage, including some fairly basic ones. The Wizard can also leave you with a fair bit of manual work or cleanup to do, depending on what you’re building.

In order to better understand the Wizard, I figure now’s the time to spell out exactly what records actually get created by the wizard. To do this, we’ll go through the different options for configuring a list (we care mostly about displaying organization entities, so that’s the focus of this article) and then see exactly what configurations are created with each and what changes occur with the different settings. If you aren’t familiar with the Wizard, I explain the steps for using it here. Read that first, then come back – this article is more of a deep dive.

Continue reading “A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard”

Basic Portal Entity Permissions and the Create Content Wizard

In the last article I wrote on this subject, we talked a bit about the Create Portal Content wizard. In that article, we walked through creating a list of leads that displays on the portal. Anyone can access the list, and it’s read-only. Where can we go from here?

Perhaps we don’t want to allow any anonymous users to see our lead list because we only share this information with partners, for example. In this case, we want the ability to create new leads or edit existing leads from the portal, or to take actions on those leads. In other words, we want a secure list of leads that can be modified by those with the appropriate permissions.

For now, let’s not worry about the realism of this scenario.  In a future post, I’ll show you how to build out an awesome portal, and we’ll look in more detail at a realistic business use case at that time. For now, let’s use this simple example to build our knowledge of how to manage permissions for entities exposed on the portal.

Continue reading “Basic Portal Entity Permissions and the Create Content Wizard”