Monthly Archives: June 2019

More checkboxes in PCF! As a TreeView this time


Did you ever have to tag records? What if we could organize those tags into a hierarchy, and, then, present them as a tree so the user could check off a few tags to identify the record?

Maybe it would look somewhat similar to this – at the top, there is a tree version, and at the bottom there is a usual subgrid:

And, yes, that’s PCF in action again.

If you wanted to try the control, you can download solution from github:

There are two more controls there, and, if you need the source codes, they are all there as well.

But how do you set it up?

1. Create an entity for the tags


Set up a hierarchy for that entity by creating a self-referencing lookup field(see above) and making that a hierarchy relationship(see below):


The hierarchy is not required, but that’s what you can use later when you need to find all records “under” one of the parent tags, for example.

2. Create an N:N relationship between the entity you want to tag and the tags entity


3. Add a few tags, organize them into a hierarchy


4. Add a subgrid to the form for the entity you’ll be tagging



5. Set up Tree Relationships control for that subgrid



I think this can be improved a little more – technically, I might be able to get either the relationship name or the relationship entity name through a webapi call. For now, though, all 6 attributes should be set.

Save, publish, and enjoy the results.

PS. Any known issues you might ask? Right now, when selecting a section in the example above, all the paragraphs will be selected as well, but only the section tag will be linked to the record. And there is a similar issue around “deselecting”. That’s to be fixed soon.

PPS. Update (June 27) – that issue above has been fixed.



Creating a custom PCF control for a subgrid – a few findings so far

When creating a custom PCF control for a subgrid, how do you display “add new item”, “quick find”, and other commands/actions/navigation items which you would normally see accompanying the subgrids on the forms?


That’s what I was recently asking in the community forums:

Once again, folks from the PCF team have raised to the challenge and provided the answer. It did not come without a few caveats, though.

When defining a dataset in the control manifest file, I can add the following attribute:

<data-set name=”tableGrid” display-name-key=”Table Grid” cds-data-set-options=” displayCommandBar:true;displayViewSelector:false;displayQuickFind:true”>…

This instructs model-driven form to display the command bar, not to display the view selector, and to display the quick find (they may have to be enabled when adding grid to the form in the designer, too).

This did not work at first, though, and I was getting the following error when trying to build the control:

Manifest validation error: instance.manifest.control[0].data-set[0].$ additionalProperty “cds-data-set-options” exists in instance when not allowed

This error, as it turned out, was caused by a setting in the ManifestSchema.json file located in the which the node_modules\pcf-scripts subfolder:

Manifestschema.json (which is in the node_modules\pcf-scripts subfolder) had this:

  “dataSetAttribs”: {
“type”: “object”,
“properties”: {
“name”: { “type”: “string” },
“display-name-key”: { “type”: “string” },
“description-key”: { “type”: “string” }
“required”: [“name”, “display-name-key”],
“additionalProperties”: false

Using “true” for additionalProperties did the trick – I was able to build the control, and I got the quick find & the command bard displayed on the form.

Well, if you look at the community thread I mentioned above, you’ll see this might not be supported in the future. Although, on the other hand, we can probably figure out how to add those parameters directly to the resulting customizations.xml file even if we can’t add them through the control’s manifest.

So far so good, but there are a few more things there.

The whole purpose of the control above was to basically display the same grid as usual except that I wanted to have a special on/off switch control for the two-options field.

If kind of worked, but, if you compare that screenshot above with the screenshot below, you’ll see how the second column is different now:


This is because my Quick Find view is not using the same set of columns as the original view, so, even though the control is expecting that there will be a Boolean attribute in the second column, and, normally, that’s how it is if the selected view is configured properly, that quick find (even though useful otherwise) starts breaking this perfect picture.

Can’t see any good solutions for this. I might add code to look at the column and only display that switch when it’s a two-options field, but, it seems, I’d have to re-create out-of-the-box rendering then(for all the different attribute types), and I’m not sure I’m really up to it. So, for now, I’ll probably just have to remove quick find.

As for the paging, it seems it has to be custom. As far as I can see, there is no way around it yet.

One other useful feature I did not realize was there is the ability to add default values to the parameters. If not for Guido Preite who provided the solution here:, I might still be looking.

All I had to do is add default-value attribute to the control property:

<property name=”optionsMapping” display-name-key=”Options Mapping” description-key=”Options Mapping” of-type=”SingleLine.Text” usage=”input” required=”true” default-value=”True:True;False:False” />

Now that I have the command bar and I can add a default value… it seems it’s time to work on a few improvements for the CheckBoxList control since I need to:

  • Add a few configuration settings
  • Figure out what to do with the options that are now showing up in the dropdown below – I want the ability to add new items, but I’m not sure Show As and some other options make sense. Besides, there is no “delete”… which probably have something to do with my control not supporting item selections yet:


This is probably to be continued…

The SOAP endpoint is dying – long live the Organization Service!


This post may have no practical meaning, really. Well, except, maybe, that the next time somebody tells you “Organization Service has been deprecated” you can say confidently that the rumors of its death have been greatly exaggerated.

I used to think that the Organization Service is going away, it’s getting replaced by Web API, and this was all based on the announcements like the one you can find here:

“The .NET assemblies for the Organization service currently use a 2011 SOAP endpoint which has been deprecated. The SDK assemblies will eventually be migrated to internally use the Web API instead of the 2011 SOAP endpoint.”

That used to give me shivers, since the Organization Service has proved to be very reliable and capable over the years. How could it possibly be deprecated and disappear without causing some kind of domino effect?

Earlier today, though, I read something that turned this all around:

“The Web API provides a RESTful programming experience but ultimately all data operations go through the underlying organization service.”

The quote above comes directly from this page:

How come WebAPI is using the Organization Service which is going to be deprecated? Is it all going to break down?

The answer was always right there, I just had to read those announcements carefully.

The Organization Service is going to stay. It’s the endpoint which is going to be deprecated… At least that’s what it sounds like if you keep in mind that all the announcements have always been about the SOAP endpoint, and not about the whole service.

I am not sure of whether the diagram below is 100% accurate, but it seems to be close enough to what all those links are talking about:


The diagram above shows current state.

And the diagram below shows future state:


The backend is not necessarily going anywhere. It’s the client side which is going to be updated – a few pieces will disappear, and, instead, everything will be rerouted through Web API. Which, in turn, will keep working with the Organization Service.

As I wrote at the beginning – there is not a lot of practical value in this knowledge except that, maybe, it adds a bit of peace of mind when you are thinking about what’s going to happen when the SOAP endpoint is finally taken away.

Other that that, the clock is still ticking:

A PCF subgrid to check off related items quickly


Sometimes, all we need from a subgrid is to show us the list of checkboxes.

For instance, imagine an inspection entity. A vehicle inspection maybe… Every inspection would have a list of standard inspection items associated with it. If only there were an easy way to check off all those items quickly.

Of course we can use an out-of-the-box editable subgrid, but, surprisingly, it does not support “checkboxes”. For the two-option fields, we will only be able to see yes/no dropdowns in such a subgrid.

That, of course, will make the whole process way more click-consuming than it should be.

So, what if we could do something like this:


I probably can’t, really, call it a production-ready control yet since there are a few assumptions made there which are not too flexible:

  • The underlying view selected for the subgrid has to have exactly two columns
  • The first column would be anything, and the second column would be a two-option field
  • This control does not support paging, so the subgrid  should be set up to display enough rows
  • Those “pass”/”fail” are not configurable yet
  • There is no “add” button – the idea is that, in that example with vehicle inspections, all the “subitems” will be added to the parent record through a workflow so there is no need to add/delete anything using this control


And, besides, it might not reflow too well.

Actually, what I just wrote perfectly illustrates a couple of things:

  • PCF has great potential
  • However, PCF is for developers. Even more, if you want to get good results quickly, you may need good front-end developers

That said, the control above is functional, so, if you wanted to see the code and/or if you wanted to try the control, here is how you can do it.

There is a github repository:

You will find this control in the Controls/CheckBoxList subfolder

If you only wanted to download the solution file, you’ll find it here:

That solution file includes one more control, too (have a look at my other post: )

It should be easy to set it up(just remember to use a view with two columns – the first one for the “name” and the second one for the two-options field) :


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