The Form Component Control promotes the PCFs to the next level

Did you ever developed a UI component like a PCF or a WebResource for an entity form, and later you get the requirement to make it work also for a child entity? For instance you make a PCF for contacts subgrid on the account form, and the you should make this PCF work in the appointment form for the corresponding account? I had this requirement a few times. I’ve tried to host the PCF together with a form using the Quick View Form, but that doesn’t work. So until now, the only solution was to make some more configurations and write some more code, in order to make it also work in another host (not the real parent form, where it was designed).

As soon as the Form Component Control was announced (here the docs), I wanted to try it out. And finaly I’ve got the time for this. Aaaaand…. it works! And not only that: once again I was surprized that it goes beyond what I was expecting in the first place, because it works for a regarding column too.

At the time I wrote this blog, the Form Component Control is still in preview, so we cannot use it in production right now, but it could be important to know that this problem will be solved soon.

The use case

First things first. Let’s name a use case: we have an account, which of course has an 1:n relationship with contacts. Let’s imagine that we’ve made a dataset PCF for showing the contacts. The user who is making the appointment for the contact, should be able to see the contact PCF for the regarding account without leaving the form.

And that’s the result:

• 🟡Yellow border – appointment form
• 🔴Red border – Regarding. On the right side, the regarding is rendered using Form Component Control
• 🔵Blue border: Contacts subgrid corresponding to the regarding account. The contacts are rendered using my ColorfulOptionsetGrid PCF Control , which can be found at the pcf.gallery
• 🟢Green border: Contacts subgrid corresponding to the regarding account. This time I’ve chosen the 1st party Editable Grid PCF, which allows me to even make inline changes.

Isn’t it mind blowing? Ok, my contact form is a little noisy; if I want only the subgrids, I would need a dedicated form. And it’s only showing the first tab, and there are a few more limitations. But I get to see everything at a glance, without having to change something in the programming. I love this.

The configuration

For a more detailed explanation about using and configuring the Form Component Control, please visit the docs.

Here is how the customizing for my appointment form looks like:

It is a little tricky to configure the PCF. The property called “Forms” need to be something like this:

<QuickForms><QuickFormIds><QuickFormId entityname="account">8448b78f-8f42-454e-8e2a-f8196b0419af</QuickFormId></QuickFormIds></QuickForms>

The only variable parts of this is the entityName and the id of the form. If you make a mistake, you just don’t see it on the form.
At first I’ve wondered why it was that complicated to configure the PCF. I just thought that two properties instead would have been much better: one for the entity and one for the formId. I guess I’ll need to check the docs every time I need to configure this, because I cannot memorize this. But soon enough I’ve understood that there is a very good reason behind this.

# Form Component Control for a regarding column (attribute)

Then I’ve started to play with this. What happens if in the appointment the regarding is empty or maybe another entity (table)? An opportunity or contact for instance? In both cases, we get the message “Source record not selected”

What if I want the Form Component Control to show something also if the regarding is a contact? And then I’ve understood: the configuration is that complicated, because it should allow us to choose for each entity another form. Maybe it was clear for you from the beginning, and now when I think back, I have no idea why I didn’t thought at this in the first place, but I’m really excited since this works too.

So a configuration for a regarding column (attribute) would look like this (this time formatted, for a better reading):

<QuickForms>
  <QuickFormIds>
    <QuickFormId entityname="account">8448b78f-8f42-454e-8e2a-f8196b0419af</QuickFormId>
    <QuickFormId entityname="contact">1fed44d1-ae68-4a41-bd2b-f13acac4acfa</QuickFormId>
  </QuickFormIds>
</QuickForms>

Af course I’ve removed the spaces when I’ve tried to paste this in the control configuration page, but then I’ve noticed that the string gets cut. There is still the limitation of the string length when it comes to PCF properties; this bug is still there since quite a while, but in the community forum, Hemant Gaur told us that this is a bug, so I hope it will get fixed.
Until then, there is a trick to overcome this: it’s not a server side limitation, but only on the client side. So we can change the maxLength using the browser developer tools.

1. Open the edit window for configuring the property “Forms”

2. Click on the text input. This will highlight the corresponding HTML element, and you find there the maxLength=”160″. By double clicking it, you can change it

3. I’ve changed it to 1000

4. After than you can check that the complete string can be pasted and we can save it.

Now we have it:

Summary

Using the first party PCF for forms in forms, we can break out of the form limitations and show records which are not directly related with the form (second level relationships). We can display them even using another PCFs (or dataset PCFs). And when we have a regarding column, the form in form will automatically get siwtched.

Did I said that I love this already? 😉