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. It also has its limitations. There are several scenarios that simply aren’t represented by the Wizard, including some fairly basic ones. But there’s also a fair bit of manual work/cleanup you’ll need to do depending on what exactly you are going for.

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 see exactly what configurations are created with the different options and focus on what changes 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”

Building the Perfect Portal Team

Recently I participated in a group discussion with Colin Vermander about what it takes to have a successful implementation of Dynamics 365 Portals. Among many other factors that I’m sure we’ll discuss in the future, one that struck me is how to build the perfect Portals Implementation team

I thought it would be fun to take a look at the skillsets that are needed to build that team, and the roles associated with those skillsets. Now let’s make the distinction clear before we get started that many of these roles overlap, and the people who fill these roles simply need to have the skillsets required. Very often, one person might fill multiple roles on a smaller project. For example, the Business Analyst and Functional Consultant might be the same person. Conversely, on large implementations with tight deadlines, you might have a very large team with multiple workstreams. Each workstream might have a team of BAs, its own dedicated functional, solution architect, and development team. The golden rule at the end of the day is to ensure that the project is not understaffed, and that each of the below skillsets is taken into consideration when building your team.

Also note, that this article tries to be methodology-agnostic as much as possible. Some roles might only apply to certain methodologies – for example if you are using scrum you’ll need a scrum master, etc. Alright, without further adieu, let’s get down to it.

Continue reading “Building the Perfect Portal Team”

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.

First, let’s go back and re-create our list using the wizard (I’ll show you how to modify an existing list in a future post). We want to do the following:

  1. Sign in to Dynamics 365.
  2. Go to Portals > Administration > Portal Management. The Portal Management page is displayed.
  3. Select Create Portal Content. The Create Portal Content window appears.
  4. Specify the basic required details. At a minimum:
    1. Your selected website
    2. The Page Name
    3. The Page Title
    4. Layout: The Page Template – Choose Full Page for this example
    5. Parent page in the content hierarchy: pre-populated with the Home page.
    6. Publishing Status
  5. Finally, for a basic page, set Display organization entity in the portal to Yes.
  6. Now let’s re-create our leads list with some different options selected:
      1. Select Entity: Lead (lead)
      2. Views: All Leads
      3. Form: Web Form (for now)
      4. Allow record creation? – Yes
      5. Allow anonymous access? – No
      6. Allow record editing? – Yes
      7. Restrict records owned by the user – No (we’ll explore this option later)

Now, let’s see what has happened on the portal. Load up your portal and navigate to the Leads List

As you can see, you can no longer access the page anonymously. However, it is possible to allow a certain degree of record creation and editing to anonymous users.  In fact, this functionality is key to certain scenarios.  We’ll explore this more thoroughly in – you guessed it – a future article! For now, let’s just look at how permissions work.

First, as a user of the portal, how do you gain access to this list? Well, right now the only requirement is to log in. We’ll look at the CRM side of things in a moment, but first things first: let’s create a portal user account by signing up:

  1. On the portal, Click on Sign In on the upper right-hand side of the main navigation.

  1. Now select Register.

  1. Fill in the required details.
  1. You don’t need to confirm your email. Once you click Register, you are signed in. Fill out your profile with a first and last name and click Save.

How does all this work? Anyone familiar with portals will know that at this point a contact record has been created for this user in Dynamics – you can confirm this by searching for the contact with the first and last name that match what you entered when you registered on the portal. You also may have guessed that this contact is associated with the default web role by … well, by default. But wait – if you try to navigate to the leads list page, you’ll find that you still don’t have access to the list! That’s because the kid gloves have been taken off. By default, a different set of permissions exist for leads, so we’ll need to override that by creating an Entity Permission for the lead entity and granting it to the default web role.

  1. In Dynamics 365, go to Portals > Security > Entity Permissions.
  2. Create a new Entity Permission record.
  3. Enter a Name. This is just for reference; choose a name that will help you remember which record contains the permission you are creating.
  4. Choose Lead (lead) as the name of the entity for which you’re creating the permission.
  5. For the scope, choose Global: this is going to keep things simple and give access to all leads in the system to anyone with this permission.
  6. Assign the Privileges Read, Write, and Create.

  1. Click Save.
  1. Once the record is saved, scroll down to the Web Roles subgrid. From here, add the Authenticated Users role (this is the default web role).

NOTE: Regarding the topic of scope, I will be posting a full article on this topic alone – it’s a source of much confusion for people trying to configure out-of-the-box portals. For now, I suggest you read the Microsoft documentation on the subject.          

Now anyone who is authenticated will have access to all lead records in the system. Not only can we see a list of leads, we can also click on the individual rows to view the details of those records.

By clicking on the action dropdown on the right-hand side of each row, you can also access an Edit form (why the Edit and Details forms are separated by default is a bit of a design mystery, but it’s good to know the option is there – you can remove one or the other down the road).

Finally, the Create button (shown in the above screenshot) enables you to create a new lead.

You can get more granular with the permissions that you add to a given web role as well. For example, in this case we did not give Delete permission (and in fact, you rarely would), but you could, for instance, give Create but not Write (update) permission to a user role, or vice versa.

Now, let’s get a bit fancier with our example. Say, for instance, that this Leads List is part of a partner portal, where we want to present leads to those in our partner network, and that anyone who has a portal user account is a partner (we’ll go through a full example of this scenario in a future post / series). In this case, most users are going to be in the Sales Manager role, a role that we can assign to users of the portal in order to give them access to leads that we have assigned to them or that they have created themselves – but no other leads.

The first step is to create an Entity Permission record to grant this permission set:

  1. In Dynamics 365, Go to Portals > Security > Entity Permissions.
  2. Open the entity permission record you created earlier in this exercise.
  3. For the scope, change the value from Global to Contact. This will change the permission so that it grants row-level access to only those records that are related to the signed-in user’s Contact record via a relationship that we specify.
  4. Choose the relationship that will determine related records. In many cases you will be using a new or custom relationship, but in this case let’s use the out-of-the-box N:1 relationship lead_parent_contact.
  5. Click Save.
  6. Once the record is saved, scroll down to the Web Roles subgrid. From here remove the Authenticated Users role. We’ll create a new role called “Sales Manager” that we’ll assign to our portal user.
    1. Click the plus sign to add an existing web role, and then click the search icon.
    2. Click New.
    3. Set the Name of the new record to “Sales Manager,” and make sure the Website is set to “Community Portal” or whatever portal you are using
    4. Click Save & Close.
  1. Now your new permission is now associated to the Entity Permission record.

You now need to associate it to the contact record for your portal user.

  1. Navigate to Portals > Security > Contacts and find the contact you created previously.
  2. Open that contact record
  3. Switch to the Portal Contact form

To finish, Under Details > Web Roles, add the Sales Manager web role.

Now this Contact should only have access to leads that are related via the relationship we specified on the permission record – right now, there are none, since we haven’t been using this relationship yet. Let’s assign a couple of leads to this contact by navigating to the lead in the system and setting the lead_parent_contact relationship. To do this, we’ll need to add this relationship to a form, since it isn’t being used anywhere yet. We could add it to the main Lead form, but let’s add it to the form called Web Form instead. Recall that this is the form that we are using on the portal – we selected it earlier when using the Create Portal Content wizard.

 

Now, add the contact to a few leads …

… and voilà: on the portal, we have access to those leads, but only those leads!

Interestingly, right now you have the ability to create a new lead, but you won’t have access to it once it’s created. This would require setting the lead_parent_contact relationship when the lead is saved (I’ll show you how to fix this in a future article, so stay tuned). Also, notice that if you click into one of the leads, the lookup for Parent Contact will appear, but you won’t have access to set the relationship to any other contact in the system besides your own. This is because you don’t have append or append to permission for Lead, and you don’t have permissions for contacts in the system.

This makes sense – the sales manager is a partner and shouldn’t be assigning leads to just anyone. In a future article I’ll increase the realism and complexity of this scenario, but for now, let’s add a second custom web role called Channel Manager that can be used to access all leads in the system and assign them to contacts, from the portal.

  1. First register again on the portal with a new login. If you don’t want to be bothered registering again, you can use the default Administrator contact and assign it the Channel Manager web role that you are about to create.
  2. Create a new Entity Permission record – again for the Lead (lead) entity.
  3. For the scope, choose Global again – this time, it makes sense because the Channel Manager should have access to all leads in the system.
  4. Assign the privileges Read, WriteAppend, Append to, and Create.
  5. Save the web role and assign it to the contact of your choosing.

Now, log out of the portal and log in as the Channel Manager contact. You’ll see that not only do you have access to all leads in the system, but you also have the ability to assign leads to contacts by using the lookup field on the edit form to set the Parent Contact for the lead. You can test this by assigning a new lead to the contact that you created at the start of this exercise, then logging out and logging in as that contact and checking the Leads List.

Hopefully you’ve had fun with this – but there is still so much more to cover! I could probably talk about this stuff forever, but for now you’ll have to wait for the next post in this series. That said, expect it a little sooner this time and for new posts to become more frequent.

Thanks for reading!

Embedded Canvas Apps within Model-Driven Forms

Just this past December, Microsoft announced the ability to enrich model-driven forms with embedded canvas apps – and this is really exciting. Since I first started working with the power platform, the fact that canvas apps and model-driven apps don’t really play together has seemed a notable limitation. This enhancement really helps bring everything closer together because we can get the same pixel-perfect purpose-driven UI that we’ve come to love (and we all know we do) about canvas apps but within a fully functional model-driven application. In case you are wondering, yes this does potentially open the door to embedding canvas apps within UCI for Dynamics 365 as well (since UCI for Dynamics is essentially a model-driven app).

First off, it takes only a few clicks to embed a canvas app on a model-driven form. Canvas apps are easy to develop (hence the somewhat-maligned concept of the citizen developer) and you can craft very nice visual layouts with “no coding” required (in fact it’s the same level of coding that you’d be using with custom excel apps for example). Furthermore, to bring in and display data from external services, you can choose from a long list of connectors that PowerApps offers for popular services such as SharePoint and Office365 or they can create custom connectors. Finally – and this is important – you get the context of the model-driven form passed in to the canvas app – including the current record or list of related records.

Example from Microsoft:

Canvas App used to display the Contacts of an Account in a visual format

While you are building you Canvas app in PowerApps App Builder, you can get the context from your model-driven form via the Data element of a special control called ModelDrivenFormIntegration:


ModelDrivenFormIntegration.Data is a list of records. If you Embed the app into a sub-grid, the context passed to the canvas app from the form will be a list of related records. If you instead embed into a field, the current record of the form is passed as the context to the canvas app. In this case you would use the First expression and dot notation to access the objects attributes i.e. First(ModelDrivenFormIntegration.Data).EmailAddress1. 

Once you’ve made the changes to your canvas app to get and use the context, it’s time to save, publish and embed the app into your form. You can either embed into a field or into a sub-grid. As mentioned, use a (single line of text) field if you want to pass the current record to the app, and use a sub-grid if you want to pass a list of related records.

To embed into a field, add the field to your form and edit its properties:

Note that you set the Control to Canvas App for Web, not mobile or Tablet. Also note the App ID that you provide

It should be noted:

  • You must set the Control to enabled for Web only, not Phone or Tablet
  • You can only embed one canvas app per form
  • App ID must be set by customize (Open existing app then save, publish to create link to control)

To Embed a Sub-Grid, add a Sub-Grid and edit its properties:

It should be noted:

  • Works the same as the field properties except here you specify a View Name
  • Fetchxml of view is result set

Full instructions for embedding can also be found in the Microsoft Preview documentation. Once you’ve embedded you can make use of the data in your canvas App, which will behave like an integral part of your model-driven form with a few limitations. One such limitation is that you cannot directly edit items using the context (yet!). You can however create another CDS data source and pass your context item to a LookUp function i.e. LookUp(Accounts, accountid = First(ModelDrivenFormIntegration.Data).AccountId)

Of course, you may have guessed that being restricted to a single record or list of records coming from a form is a bit of a. . . well, restriction! You’ll be pleased to know that you can also connect and grab data from other data sources by using connectors. there are over 230 Built-in Connectors and you can also build you own using an API.

I look forward to diving more into this functionality in the future. Thanks for Reading and enjoy!

Dynamics 365 Hybrid Interface

Microsoft’s Power platform is the direction to be looking at if you are involved with Dynamics 365 implementations in any sense. Built on the Common Data Model (CDM), Model Driven Apps – including yes, Dynamics 365 moving forward with version 9 – will be using the Unified Common Interface or UCI for short.

Many Articles have been written about the Unified Common Interface, including it’s ease of use and slick user experience. Much fuss has also of course been made about it’s limitations – which are mostly temporary. These limitations include but are not limited to:

  • Advanced Find
  • Bulk Edit
  • Merge Records
  • Record Sharing

There are various tricks that can be used to access the old interface, and these are well documented (one less documented way is to simply add “?forceClassic=1” to the end of the URL in your browser. However, if you like the new interface and wish to fully adopt it, instead of using the old interface for these functionalities a hybrid mode is possible which enables the aforementioned features in the new interface to a degree.

These features are enabled through a setting in System Settings (which you ironically need to access the old interface to get to).

  • Go to Settings > Administration > System Settings
  • Select the “General” tab
  • scroll way down…to the bottom…
  • Set “Enable embedding of certain legacy dialogs in Unified Interface browser client” to “Yes”

blogpostdec212018

After enabling, the hybrid experience will enable a bunch of options that utilize the old interface (and cause the old interface to pop up in a rather glaring fashion) in the Unified Interface command bar.

hybrid-edit-merge-share

Pretty nice. Enjoy!

Coming up soon, the next part in my series on Portal Management. View part one here.

Adding Portal Content Faster and Easier with the New Portal Management Centre

There’s been lots of talk about the new portal management capabilities in the latest release of Dynamics 365 and portals. Managing content and adding web pages in portals has up until now been most easily done using the front-side editor when it comes to standard content; meanwhile adding views or forms for other non-portal entities has always been a manual process involving creating entity forms and entity lists on the CRM backend. Indeed, the pain and confusion involved with the process of doing so has been a big blocker in terms of adoption of the Portals as a turn-key solution.

This has changed somewhat with the latest releases, with a new Portal Management Center right in Dynamics 365 Web Application which makes adding content a bit quicker and easier, especially if your goal is surfacing Dynamics entities that don’t belong to the portals site map concept.

First off, in order to use the Portal Management area of the Dynamics Portal module, your CRM security role must have full read/write/ permissions to all of the Portal entities administered by this functionality: namely Entity FormsEntity Lists, and Web Pages. Assuming you are able to access it you’ll notice that there are two options. The first is to Create Portal Content, and the second is to Enable Analytics. We might look at the second of these options in a future post, but today we are talking about the first: The Create Portal Content Wizard.

Please Note: In order to try this out you’ll obviously need to have a portal available for you to use and play around with. If you haven’t already done so, I’d suggest signing up for a Dynamics 365 trial. Also, this post assumes you are already familiar with front-side editing and portal content management basics. We’ll post on those topics at a later time, but they are well-documented on MSDN.

The simplest task to perform using the Portal Management Center is simply to create a web page containing basic content. This is typically done using front-side editing, and front-editing is still perhaps the optimal tool for this task. However, if you are going to create Web Pages inside the Dynamics Web Application, the Create Portal Content wizard is a more streamlined method of doing so than manually creating the records using basic CRM forms.

TO CREATE A WEB PAGE

  1. Sign in to Dynamics 365.
  2. Go to Portals > Administration > Portal Management. The Portal Management page is displayed. 
  3. Select Create Portal Content. The Create Portal Content window appears. 
  4. Specify the required details. At a minimum:
    • Select your website; prepopulated if only one website is available. The list is sorted alphabetically by the website name.
    • The Page Name.
    • Page Title (required for some reason, even though it’s not required by the system).
    • LayoutThe Page Template.
    • Parent page in the content hierarchy; prepopulated with the Home page.
    • Publishing Status
    • Finally, for a basic page, set Expose organization entities in the portal to false. We’ll get to this!

The web page you create here is going to be pretty basic –just some simple content using an out-of-the-box Portals page template or one that’s been created by your team. When you click Create, the shiny new record will open in CRM, and you will be able to navigate to the Page on the portal (by typing in the URL directly, for example). There won’t be any content yet –you’ll create that separately.

EXCITING STUFF, RIGHT?

OK, so this by itself may not be all that awe-inspiring to those who have configured content for Dynamics Portals before, but let’s take a moment to appreciate just how few clicks were actually involved here, and just how fast that process actually was. This is shiny new functionality –a true wizard-like interface for creating content for portals– that’s been missing for a long time.

The really exciting new functionality, however, is unlocked when you choose to expose organization entities on the portal. This functionality actually allows for a view (list) of just about any entity in the CRM to be exposed on the portal, along with create and edit capabilities, should you choose to enable them. Finally, something as straightforward as exposing a list of leads on the portal, which has always required some rather complex configuration, is just a few clicks away.

This time, let’s create a web page that surfaces said list of leads. A publicly exposed list of leads may not seem like a realistic use case in and of itself –and that’s true– but bear in mind we aren’t discussing security or access permissions today (with which you could lock down this list to only certain users) nor are we really discussing verticals. This is more about exposing any kind of records from the CRM quickly and easily. There are many different possible scenarios where you would want to expose a list of records on the portal, with the ability to edit or insert from the portal being a part of many such scenarios as well.

To set this up, we’ll be creating a web page using the same method as before, but making use of some advanced options:

  1. Sign in to Dynamics 365.
  2. Go to Portals > Administration > Portal Management. The Portal Management page is displayed.
  3. Select Create Portal Content. The Create Portal Content window appears.
  4. Specify the basic required details. At a minimum:
    • Select your website; prepopulated if only one website is available. The list is sorted alphabetically by the website name.
    • The Page Name.
    • Page Title (required for some reason, even though it’s not required by the system).
    • LayoutThe Page Template.
    • Parent page in the content hierarchy; prepopulated with the Home page.
    • Publishing Status
    • Finally, for a basic page, set Expose organization entities in the portal to TRUE this time.
  5. This is where things get interesting. The wizard will now give you some options that will result in Entity Listsand Entity Forms being created. Without getting too deep into the details in this post (a future post maybe), let’s look at the options:
    • Select Entity: The entity that you want to expose.
    • Select Views: Choose the views you want to add to the view. If more than one is selected, portal users will be able to switch between them.
    • Select Form: This is the form to be used for reading individual records when you drill into the list.*
    • Allow Record Creation? Select if you want people to be able to insert new records.
    • Allow Anonymous Access? Should people who are not signed in be able to see the list? If you select NO, you will need to set up Entity Permissions, so choose YES for now. If you choose NO to Allow Anonymous Access, more options become available (we’ll skip this for today).
    • Allow Record Editing? Exactly as the name implies. If yes is selected, the Read form becomes an edit form if the portal user has write permissions.
    • Contact Relationship: If you want to show only records that are related to the sign-in user, what’s the relationship between them? It’s an advanced option we’ll talk about in a future post.
    • Restrict Records Owned by the User: They’ll only be able to access their own records (needs above mentioned contact relationship to be defined)

* Please Note: I recommend creating specific forms for the portal, as the OOTB Dynamics “Information” forms, while well-suited for the CRM web application, are not as well suited to being displayed on the portal. It’s a good idea to name these forms with a naming convention so that they can be easily selected while setting up Entity Forms, whether it’s manually or using the Create Portal Content Wizard

* Also Note: You cannot enable Allow Record Editing if anonymous access is allowed. It may seem strange that you can enable Create for anonymous customers, but there you have it. That said, whatever we create here will respect Entity Permissions, a topic for another day.

LET’S LOOK AT A SIMPLE EXAMPLE.

We’ll keep most of the options either turned off or simple for now. Let’s just create a list of leads on the portal:

Here are all the options displayed:

Here are the options we want:

Click Create, and then wait for it to finish spinning; once it’s complete, you’ll be able to navigate to the page on the portal by typing in the URL directly, or by adding a Web Link to the page on the primary navigation.

(Creating a web link…)

…and presto!

So, now we have a list of leads. If you sign out, you’ll notice that it’s accessible whether you are signed in or not. Furthermore, you can click on the linked Name fields of each of the rows to view more details – but only if you have permissions set up, oddly enough. Same goes for the create functionality. This is a bit odd, since there are in fact configuration settings possible which would enable BOTH of these functions with no configuration of permissions, if they were the defaults. Ah, the mysteries of the Dynamics Product Team!

Regardless, we’ve got, at the very least, a read-only list that can be made a lot more useful with a bit of extra configuration – configuration that we’ll cover in Part 2. Don’t miss it!

In the meantime, this post has demonstrated just how easy it is to get up and running with the Create Portal Content functionality of Portal Management in Dynamics. I hope you found this useful.

See you next time!

 

This blog post is one I wrote originally for KPMG Adoxio – It was originally posted over on their tech blog. Go check it out!

The Journey Begins

Hi Everyone,

Yes if you are reading this, this is the default wordpress blog post that automatically gets set up when I sign up for wordpress! Impressive right? Well, i’m 35 years old and I have been thinking about doing this for 10+years.  Not sure if this is going to be one of those stuffy tech blogs, or if there’s going to be a bit more variety.  I’m leaning towards the latter.

I’m still learning my way around blogging, so i’m keeping my first post pretty minimal, and i’m going to see just how far I take this thing.  Thanks everyone for checking out my blog!

If you are curious about me – I’m an experienced consultant with a demonstrated history of working in the Microsoft sphere and Dynamics in particular. I’m skilled in training, requirements analysis, .NET Framework, C#, product development, and Visual Studio. I work for KPMG Adoxio

I’m also passionate about global geopolitical and environmental issues. I work with a group called Vision of Earth during my spare time. Go check out some of the articles I’ve written there!

I earned a Master of Science (M.Sc.) in Computer Science from University of Regina and worked for 7+ years in product development before transitioning to a consultant role. I have a lovely wife and a (currently) 5-year-old son. They are the world to me.

Good company in a journey makes the way seem shorter. — Izaak Walton

post