Monthly Archives: June 2019

SharePoint integration for P2 Plan users


Before you read this post, here is the disclaimer: whatever I write below is my own interpretation which you may want to confirm with Microsoft.

Why is there a disclaimer? Well, I’m going to talk licensing below…

So, you know there are two different types of CDS (Dynamics CDS and regular CDS). I am not exactly sure what the technical difference is between those two, but, when you are creating a Dynamics 365 instance, you are getting Dynamics CDS. When you are creating a PowerApps environment, you are getting a regular CDS.

In the Dynamics CDS, you can deploy various Dynamics first-party applications. In the regular CDS, you can’t do that.

However, Sharepoint integration is not considered a first-party application. It’s a functionality included into the Dynamics CDS and not exposed in the regular CDS.

Outlook integration is slightly different, since there is a first-party application now. However, with the Outlook integration coming in Wave 2, it seems PowerApps Plan 2 users are going to be able to use it in the regular CDS as well.

In other words, from the licensing standpoint, it seems nothing should be stopping P2 Plan users from utilizing either of those features. Of course, that would only be possible if either of them were available in the corresponding CDS environment.

But is there anything that’s stopping a P2 user from working in the Dynamics environment? Not really, it seems. Moreover, if you look at some of the diagrams in the licensing guide, you’ll see that P2 license is fine in that sense:

Well, of course, normally Dynamics environments are supposed to have all those first-party apps. But they don’t have to, and, even if they do, P2 users don’t have to work with those applications or with the restricted entities introduced through them.

How about Sharepoint, then? The question that came up recently was, literally, how do we get Sharepoint in the regular CDS instance for a P2 user. Well, there seem to be no way, and it’s not even scheduled for Wave 2.

But, then, we can get a Dynamics CDS instance, add P2 user to that instance, and voila – here goes Sharepoint integration:


Well… How about server-side email integration? Here it is:


And, if you thought that would be enough, we are not done yet. Once that user is given “Outlook App” role:


We can add a Dynamics 365 App for Outlook to that user:


Just to summarize: there is a P2 plan user who now has access to the Sharepoint integration and who can use Dynamics App for Outlook.

I suspect there might be an extra cost per month since you may need at least one full Dynamics 365 license to get Dynamics CDS instance, but, it seems, the rest of your users can be licensed with P2 if they are not planning to use any of the Dynamics first-party apps, and they will still have access to Sharepoint/Outlook.

Btw, if I were writing this half a year ago, I would have to mention per-instance cost, too. Don’t have to do it this time, though, since Dynamics instance pricing is storage-based now.

If it’s one tab/window or if it’s multiple tabs/windows – the choice is yours. Although, you have to be in the UCI

I like the unified interface. I did not like it when it was introduced originally, but I don’t mind it at all the way it is now.

One thing I used to not like that much about the navigation in the recent versions of Dynamics is that whenever I clicked a lookup it would just open related record in the same window. That was quite annoying, since I would have to go back and forth in the browser. Personally, I would rather have all those links in separate tabs, since, normally, I have tens of different tabs open anyway:


It’s a bit of a mess, of course, but I find it convenient.

So, when we lost the ability to open links in the new tabs/windows, and I don’t even remember right now when exactly it happened, it was quite a disappointment. What I mean is that, while in the classic interface, a lookup link normally opens up in the same window.

It’s a little better with the grids since you can right click there and use “Open in a New Window” option:


Neither of that is good enough.

It turned out, though, that there is one interesting difference between the Classic Web Interface and Unified Interface since Unified Interface does support keyboard shortcuts properly:


Just use CTRL+CLICK, and that lookup link above will open in a new tab. Use SHIFT+CLICK, and you’ll see a new window.

Small as it is, but it’s been a time saver for the last few months, ever since I’ve realized those shortcuts work in the UCISmile

How to: package and deploy a PCF control without actually doing much (if anything)


While creating a PCF control I realized at some point that building and packaging it is taking time. More importantly, it’s taking time from the developer – I don’t mind if my laptop spent some time doing all the deployment, but why would I want to also baby sit this powerful machine?

So, basically, I wanted some magic to happen along the way so that what I had on the left side of the diagram below (specifically, all the source code) smoothly flew to the right side (model-driven app)


Of course there would be things I’d still have to do, such as creating an app and updating a form. But, as far as deployment goes, I’d like the packaging and deployment to happen seamlessly.

Therefore, PowerShell to the rescue!

Note: you still have to set up your environment first (nodejs, npm, etc)

Here is how you can get it all set up:

  • Get the contents of this git repository:
  • Once it’s on your hard drive, update your system path environment variable so that it has a path to the “Setup” subfolder. Down below, the other scripts will need to be able to locate deployment.psm1, loader.ps1, and loadmodules.ps1
  • Then, you can close(or download) my sample PCF regex validation component:
  • Before you do anything else, update connection strings in the settings.ps1 (which you will find in the deployment subfolder)
  • image
  • Because of how that whole set of powershell scripts came about, both source and destination connection strings will need to be updated:
  • image

If you want, you can assign a value to the password variable instead of taking it from the console prompt every time.

Assuming you’ve done everything correctly and the environment had already been set up, you should be able to just run packageandimport.ps1, possibly enter the password, and, from there, you can just take a back sit and relax:


What the script will do is:

  • It will build the control
  • It will package that control into a solution
  • It will deploy that solution to Dynamics

In the current version you may want to review settings.ps1 and package.ps1 to see if there are any string constants you need to update (there is a relative path to the control folder, for example. It should work as is for the ValidatedInputControl)

PCF Controls – now I have my first PCF control, too


I was curious to see what writing an actual custom PowerApps component using the PowerApps Component Framework (PCF) would look like, but, up until a few days ago, there was always something in the way.  Now that I finally got some hands-on experience, it seems there are a few things which I wanted to share.

Overall, it does not look like this little experiment changed anything in my understanding of where PCF fits, who is going to use it, etc. So this other post is still relevant:

Either way, what I wanted to try is to create a custom component that would replace a regular input box and add regular expression validation. So, for example, if I had it displayed for a field which is meant to represent a phone number, I would have an error when the phone number did not follow the 10-digits US/Canada format:


Here is how that control is configured on the form:


If you want to see the source code, you will find it on github:

Of course you could probably do the same differently by adding an event handler to a regular out-of-the-box control, and, in this particular case, maybe it would not be that much better or worse, but, again, it was all about trying out the PCF.

And, of course, there were a few takeaways.

1. This all requires some HTML/Javascript experience, or, at least, understanding

Of course it’s, actually, TypeScript, not even Javascript. But, really, it’s just a matter of catching up, and you don’t need to be a TypeScript expert to start writing PCF controls.

Still, there are other things. Part of the problem is that we are, essentially, adding our own HTML controls to the screen, so we have to somehow embed them into the familiar user experience. For example, in case with the regex validations it took me a little while to realize that the event listener I used there at first did not quite fit:

this.inputElement.addEventListener(“input“, this._refreshData);

Because this kind of validations should not happen until the focus moves somewhere else. So, instead, it had to be “blur” event:

this.inputElement.addEventListener(“blur“, this._refreshData);

Actually, I ended up using both just to make error handling a little more user-friendly.


2.  CSS styles – we cannot easily re-use out-of-the-box styles, not yet at least

Model-Driven Power Apps use certain styles to display controls. However, those styles are not automatically inherited by our own PCF controls. It’s possible to add references to your own css files and implement styling that way, but, of course, there is no guarantee out-of-the-box styles won’t change moving forward, in which case all those custom controls would start looking out of place again.

With this one, it turned out that, as I was trying to figure out how to handle the css in the community forums:

Andrew Ly was hitting some of the same walls, so he submitted an idea you might want to vote for:

Although, maybe there is more to it than fonts.

3. This one is very granular, but… if you are building a PCF control and if you don’t see your changes reflected, make sure to increase the version number

There is a version # in the control manifest file:


If you don’t change it for a new build, there is a 99.9% chance your changes won’t be reflected in the user interface once you import the solution, publish all, and reload the form where you have the control added. It’s possible they’ll show up later, but I did not have that much time to wait.

For that matter, don’t hesitate to ask questions in the community forum:

It seems that the team behind PCF controls is, actually, monitoring that forum; and they are providing the answers where they can.

4. Build and deployment

Of course there is that ability to see your control outside of PowerApps/Dynamics using a test page. Have a look at the “debugging” here:

However, if you wanted to publish your control in the PowerApps/Dynamics environment, there are a few additional steps involved:

  • Increasing the version number
  • Packaging everything into a solution file
  • Importing that solution


For this(with the exception of the version # so far), I ended up using a bunch of PowerShell scripts, and you’ll find those script in the “Deployment” subfolder here:

Those should be used along with the powershell library from the other project:

More on this in the next post, though