Related sites:

Newsletter: Perspectives on Power Platform

Company: Niiranen Advisory Oy

Relational data on Model-driven forms, part 2: Form Component Control

How to make fields from a related table editable on a Power Apps Model-driven app form with the new "forms within forms" PCF control. This second part shows how to go beyond Quick View Forms and create a seamless data entry experience.

Our quest for improving the user experience of Power Apps Model-driven app forms and multi-table data models continues with this part 2 blog post. We will explore how the brand new Form Component Control enables us to essentially blend the forms from two different tables (entities) onto a single form for the user to easily interact with.

In part 1 I laid out the example scenario of a Rental Car app where a single rental event record will always have a single related car record associated with it. Please go and have a look at the details in the earlier post if you want to understand the details.

Our approach was to leverage the Quick View Form to bring in fields from the related parental table (Car) onto the child table (Rental) form. To make the data entry and editing easier we enabled the Main Form Dialog feature for the Car lookup field, which then opens the form in a modal window.

While this UX is a lot nicer than navigating between full screen forms and page loads, it’s still not all that seamless. The user will be very much aware of the fact that he/she is working on two different tables, while ultimately we’d want to show just a single page that abstracts away all this complexity of the underlying relational data model.

What is the Form Component Control?

First of all, it doesn’t have a very sexy name, that’s for sure. During the past few days of exploring the feature, I’ve had to repeatedly go back to the documentation to see what the name was. Even the product team’s announcement “editing related records on a main form in a model driven app” doesn’t sound very exciting. There’s a lot easier way to describe it:

Forms within forms.

It’s simple, and it’s very powerful. Unlike the CRM 2013 era feature of Quick View Forms, there’s no requirement to keep the forms as “view only” , nor particularly “quick” in terms of their contents. It’s just regular forms, and they can be used within other regular forms – full edit capabilities included.

Let’s add a Form Component Control onto our form and see how it works. Unlike with the Main Form Dialog feature discussed in part 1, this Form Component Control feature is unfortunately not yet available in the modern Power Apps form editor. So, we start with what we still need to do very often in the world of Model-driven apps, meaning hit the “Switch to classic” button to launch the classic Solution Explorer that dates back to CRM 2011.

On the form where we have a lookup field (in our case the Car lookup on the Rental form), let’s open its properties dialog, go to the Controls tab and click “Add control”. We can see the MS provided PCF control “Form Component Control” in there. Adding it and setting it to be the default control for our web client is easy, but the configuration requires some additional information that doesn’t have a graphical UI (maybe in the modern form editor then once this feature is supported there).

See the MS documentation page for the detailed steps to take. In short, you’ll need an XML entry that contains the table name (entityname) and the form ID of the main form you want to show for the related table. My configuration looks like this:

<QuickForms><QuickFormIds><QuickFormId entityname="cr7d0_car">2F3B241A-4E3F-4AE3-A26F-1AB7BF804636</QuickFormId></QuickFormIds></QuickForms>

Let’s publish the changes and go test out the experience of editing an existing Rental record where the Car record’s fields have been partially populated. On the place where I previously had the Quick View Form with its locked fields, there are now fields coming from the Car table form. Text fields, lookups, choice fields – they all work exactly the way they would if I was editing data that’s natively stored on the Rental record, rather than the related Car record.

The save event happens as part of the hosting form, no additional tricks required. Field validation, notifications and error handling is also integrated, regardless of whether the business logic comes from the main form or the embedded form (details in the Docs).

All in all, this works incredibly well from a user experience perspective in my initial tests. Even if you’re a Dynamics 365 or Power Apps professional you might not realize that the form actually blends two different tables into a single form.

Main form rendering options via Form Component Control

With the old Quick View Form feature, there was a separate form type you had to create for the table for this specific purpose. It was far more limited in contents and layout than the full table forms, which kind of made sense for the purposes of bringing a few key fields in read-only mode onto a the actual main form of a different table. QVF allowed single column only + no other useful controls than the subgrid:

The Form Component Control knows no such boundaries. What you can use there are the existing or new main forms for any table. If you place them within a single narrow column on a multi-column form tab, then all of the form contents will be rendered within that column. Since the Unified Interface forms are inherently responsive by default (which is a big benefit compared to Canvas app screens), everything will just reflow into a layout that would resemble a phone screen – even if you’re viewing the form on a widescreen PC monitor.

What about if we give the Form Component Control a bit more space than a 1/3 of a typical Model-driven table form? The reflow also works the other way around, meaning all of the available screen space will be used. If the area given to FCC can accommodate more columns and the source form has them, they’ll be rendered just like on the “native” viewing experience of that form.

Below is an example of an alternative form design for the Rental table. Instead of having the related Car shown in the middle of the first form tab, I’ve added a second form tab “Car” and dedicated all the space available in it to a single lookup field that has the FCC control enabled. You’ll see from the static Business Process Flow and the form header that we’re firmly on the Rental form all the time, but the second Car tab shows things like the Timeline for that car record (with a note), further tabs for the car’s Dealer, even a Quick View Form referencing the dealer account related to the Car record – all within on FCC control.

This to me is just mind-blowing! We are reaching Inception level UX here, with the main forms embedded AND rendered as a full form tab within another form. I could be on the Rental record form, adding an activity via the Timeline control that’s actually linked to the parental Car record. Not the Rental record where the app navigation, form header, Command Bar and everything else visible on the screen is telling me I’m on. I’ve effectively built a form UI that defies the laws of nature I’ve come to expect from Model-driven apps.

Sure, embedded Canvas apps could do some magic like this already earlier. The big difference is that the user interface of those screens could never match exactly that of a Model-driven app. With FCC there are no visual clues distracting the UX, as everything looks and feels like it’s part of the native experience where Microsoft owns and manages the visual side.

What about record creation instead of edit?

The one gap that exists in the inline editing story for Microsoft’s controls like the Editable Grid or this new Form Component Control is that there’s no possibility to use them for adding new rows into a table. They offer the edit experience, but no create experience. Sure, we have the Quick Create Forms feature available for contextual data entry, but it’s not really optimal. The user shouldn’t have to think about if they are editing existing entries or creating new ones. Yes, the difference between these concepts matters to the platform on a technical level. Still, unless there’s a valid business process requirement for making the data entry experience different for create and update scenarios, it’s something I’d prefer to eliminate from the UI.

When there’s a scenario where we essentially have a one-to-one relationship between tables (no “real” 1:1 relationship exists in Dataverse, but there are ways to fake it), one option would be to automatically create the related parental record behind the scenes. With this approach, at the moment when the user will proceed to entering data via the Form Component Control, the lookup field will already be populated and the experience will look pretty seamless:

What I’ve done here is to create a classic XRM workflow that runs in real-time, triggered by the create event of the Rental record. (Power Automate can’t do real-time yet, so it’s a no go for flow in this case.) The workflow will create a Car record with a placeholder name “(Undefined)” and link it to the Rental record. By the time the first save event for the new Rental record takes place, the FCC can then render the fields from this placeholder Car record on the Rental form.

In the above example GIF animation you may also spot that the Car name changes transparently from “(Undefined)” to “BMW”, due to what has been selected in the Manufacturer field. This again is another real-time workflow that’s triggered by the update event of the Car record. The end user will not need to take any actions, it’s all just the native autosave feature of Model-driven apps that populates this name field while the user is still entering data into other fields further down the Car form.


If the new Form Component Control gives us not just the read capabilities from Quick View Forms but also data edit support, then should we just stop using Quick View Forms altogether? Well, it certainly is a good question. Given that QVF dates back to the CRM 2013 era user interface technologies, FCC is much more in touch with how the modern Unified Interface client has been designed to work. It’s built using the Power Apps component framework (PCF) and should in theory be the most future proof choice for Model-driven app form design.

One downside is that the use of FCC for the pure view scenario is a bit more laborious. If we indeed would want to prevent the user from updating values from the parental record while on the child form, then these fields would need to be set as read-only on the main form itself. Which brings us to the challenge that you’ll need to keep more forms visible in the Model-driven app, whereas classic QVF’s are hidden behind the scenes and only applied as the definition when rendering the main form on which they are used.

The create scenario I talked about earlier is also a bit of challenge when analyzed deeper. If indeed the lookup from which the Form Component Control gets the related parental table record to show isn’t populated immediately, you’ll see a message saying “source record not selected”. In most cases that’s going to be quite a confusing message for the end user to encounter, given they are unlikely to have any idea about the forms magic and relational tables being used in to construct the app’s UI.

“Couldn’t we just hide that control until it the lookup has data?” Well, I can’t think of a no-code way to achieve this. You see, the problem is that the FCC essentially is the same field as the lookup field. Sure, you can have multiple instances of it on the same Model-driven app form. But you can’t use Business Rules to say “hide this field if this other field is empty”, because they are the one and the same. Quick View Forms handle this scenario much better, so let’s hope Microsoft will improve the functionality in FCC to accommodate this create/hide scenario better in future releases.


This first public preview release of the Form Component Control has a few limitations that you should be aware of. For instance, you can’t show more than a single tab from the form being rendered via FCC, which isn’t really a big issue unless you really are building an Inception app to confuse the hell out of the classic CRM users at least. Similarly, you can’t have FCC’s within FCC’s, which blocks some crazy recursion scenarios.


  1. I think it’s worth making more clear that the answer to “Couldn’t we just hide that control until the lookup has data?” is “yes”, just in a low-code way rather than in a no-code way. One could add an onchange handler to the lookup field that hides just the FCC when the lookup field value is null and unhides it when the lookup field value is not null. It could be a one-line ternary expression 🙂

    • Yes, with code it is of course possible and perfectly supported. So are many, many other things that come to the tweaking of the Model-driven forms. Since this is a current gap in the design of the Form Component Control, I believe it needs to be highlighted to Power Apps makers – some of who might be coming from the Canvas side and are exploring this alternative way of creating app UIs generated from the Dataverse data model. Quick View Forms handle this create scenario “hide if no data” requirement gracefully with no code, so hopefully FCC will soon, too.

  2. The documentation mentions some issues with using these on forms which have a Process Flow, and I note you are using them in that context in your article, have you ran into any issues in that regard?

    • Brad, I believe the issues could arise when the form that’s being embedded via Form Component Control contains a Business Process Flow. In this example the parental Car table does not have BPFs, but the child table Rental does have one. I haven’t tested embedding in a scenario where this would be the other way around. Nevertheless, since BPFs aren’t a property of the form but rather then underlying table itself, it could indeed become a limitation for using FCC.

  3. Hi retrieving a saved record, doesnt showed the parent’s record in FCC just like when lookup is selected during create. It showed “source record not selected”. Anyway to show the populated parent’s data?

    • Normally it should show the data also when opening existing records. However, I’ve also noticed strange behavior with the Form Component Control’s preview version, which appears to be a bit buggy still. Sometimes the initial load won’t show the record, but refreshing the form brings in the data. We can only hope that Microsoft improves the reliability of this control, as there are definitely many use cases where it’s a much better fit than the old Quick View Forms.

  4. In regards to the first comment posted “One could add an onchange handler to the lookup field that hides just the FCC when the lookup field value is null and unhides it when the lookup field value is not null.”, I was trying to get this to work and the onchange event never fires. Have you gotten this to work to avoid the “Source record not selected” error message? My FCC is on the first tab that is opened on the form, so maybe that has something to do with it.

  5. Hi Jukka,
    Is there any way we can refresh the form to get the latest values in the form? I have created a PCF control on target entities form to refresh but it is not working under form component control. However, it is working fine on the direct form instead of FCC. any suggestions?

    • Naveen, I’m not aware of any specific methods for form refresh with the FCC. In general there still are situations where even a basic form using the standard MS controls may fail to load correctly when embedded via FCC, so it might just be glitches with the current version.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.