top of page
Neon Smoke

Complex Forms in Power Pages

Updated: Jul 1

Ever wished you could replicate more of the Dynamics 365 capabilities in Power Apps? Whilst you may love CRM like this geeky writer, limitations do sometimes exist. Power Pages is a great product, and getting to know its various features is what truly brings the Dynamics 365 experience to life.

A fun side note: This blog post was demoed on the 19th of June at the Power Platform Community Call. You can find it from 12:29 onwards here.

The dream

Picture a very simple idea. Recreating views from Dynamics 365 into Power Pages. Features like:

  • A list of filtered data

  • Each row holds a record I can open up

  • A set of criteria and permissions defines whether I can just view record details, edit, or even add new records

  • Each record opens up a multi-tab main form in all its glory with rich functionality (lookups, subgrids etc.)

The realization

Sounds straightforward. It is all Dataverse data, we got lists, we got forms. But, here is the thing. If you go to the Options tab of a List in Power Pages Management, you will see that in the Grid Configuration, each action can only relate to one of three things:

  • A Basic Form

  • A Web Page

  • A URL

What is the problem with a Basic Form you say? Well, it only hosts a single tab of a Dynamics 365 form. You cannot directly have a multi-tab form without some cool hacks.

Let’s hack this, the Avengers way

You may remember the Avenge365 app I built to explain how you can also create a checklist automation. Blogged about it here and presented in the monthly Power Platform Community Call as well (February edition).

This solution was very much focused on Dynamics 365, Power Automate and XRMToolBox. It helps Tony and the Avengers to manage their superhero portfolio, list of protected cities and villains, monoliths, citizen concerns etc. Most importantly, it is a battle management app to support each battle. True endgame stuff. All the details around the data model, detailed Dynamics 365 app set up and the functionality screenshots are in that first blog.

Whilst the Avengers were always the CRM back-end users, I always thought about extending it to end users with Power Pages. By end users, we will consider S.H.I.E.L.D. agents who want to support the Avengers in battle management. On top of creating a general agent portal to manage their onboarding, leadership briefs etc.

Scenario, users and plans for Power Pages domination

Our brand-new portal, called S.H.I.E.L.D. Declassified, has been designed for agents who are onboarded into the Secret Ops division supporting the Avengers. From handling new agent onboarding, evangelizing about the agency’s mission, and providing access to covert Avenger battles, it is truly a one-stop shop.

Let’s look at the scenario requirements, which resemble Dynamics 365 views:

  1. A table of all Avengers battles, both active and inactive

  2. Each row holds a record an agent can open up, and see all relevant tabs

  3. If the record is for an inactive battle, only read rights apply

  4. If the record is for an active battle, both edit and read rights apply

  5. An agent also has the opportunity to add their own new battle records

  6. Each record opens up the standard multi-tab main form in all its glory

With these requirements in mind, here is the Power Pages recipe we will use:

  • 1 List with 3 types of Grid Configuration and Table Permissions (Basic & Child)

  • Filtered View to show both active and inactive (completed) battle records

  • 1 Basic Form for adding new battle records

  • 2 Multistep Forms, with 3 steps each, for reading and editing existing battle records

  • 2 Web Pages to host each of the Multistep Forms with appropriate navigation paths

Let’s get building. We will have to build the forms first, then the web pages, and finally the list.

New Battle Records – Basic Form

Before assembling our list and fancy Multistep Forms, we start with the Basic Form for the creation of new battle records. To do that, we first build it in the maker portal as part of the Battle entity.

We want to capture some basic information to begin with, so our Summary tab is enough (hence the use of a Basic Form in Power Pages).

Bonus tip: It is natural to have many forms as part of an entity in your Dynamics 365 or Model-Driven app. Since some forms will also be used for your Power Pages portal, name them accordingly. For example, I add “- Portal” for those forms going there to avoid confusion. As you collaborate with your fusion team, they will really thank you for your organization skills!

Once the portal form is ready in the maker portal, let’s go to Power Pages Management. Create a New Basic Form by selecting our previously created maker portal form called Create & Edit Battle Form - Portal and using the Summary tab.

Existing Battle Records – Edit Form

This is where the real fun starts. As I mentioned, the OOTB list feature in Power Pages does not support Multistep Forms. Instead, we will create them, host them in Web Pages and use that to connect each action in the List’s Grid Configuration.

Let’s set this up by creating a new Multistep Form called Existing Battle - Edit Multistep Form. For now just the Name and Website is enough.

One thing which is helpful to add from the start is to tick the Progress Indicator as Enabled. Gives users the opportunity to understand how far they are in their tabular view experience.

Let’s click on Save. Now we can add to the Form Steps tab through + New Form Step. Each step will represent the tabs in the form, counting from left to right. Our first tab is called Summary, so let’s name it as such since end users will see it. We specify the Target Table name, which is referring to the Battle entity. We also add the Form Name and Tab Name. Click Save & Close.

Bonus Tip: Since this is an end-user facing form, you may want to name the tabs under a relatable and simple name. This may not always be the same as the back-end experience you have given those users.

Let’s repeat the same for the tabs Villains and Battle Checklist.

Now we have the three forms, let’s make sure we have the right sequence. Since we want the Summary tab to be Step 1, Villains to be Step 2 and Battle Checklist to be Step 3, we need to go back to each step to add the Next Step as per below.

Final touch is to add the Start Step in the main Multistep Form as per below to close the loop.

Now that the steps are complete, let’s create a Web Page to host the whole Multistep Form. From the Web Pages tab of our Multistep Form, click + New Web Page.

To note we will have to also curate these two Web Pages in the Design studio.

Our finished product to behold and admire from a Power Pages Management perspective!

We did say we will have a view-only version of this form. So, let’s build that the same way, but obviously with a read-only version of the originating form and columns!

Here is what that will look like.     

Now that we have our Basic Form and x2 Multistep Forms hosted in their own Web Pages for view and edit permissions, we can go ahead and create the List.

In this post I already guide you through how to set up a filtered view for your list. The blog also covers your Grid Configuration to control what rows can be viewed or edited alongside new records being created.

In our scenario, we want a list with:

  • A filtered view of All Battles only from the Battle entity. This is based off a view of both Active and Inactive Battles.

  • In the Options tab a Grid Configuration with:

o   A New Battle button for S.H.I.E.L.D. agents to create new records 

o   A View Battle Details button for S.H.I.E.L.D. agents to read the details of both active and inactive (completed) battles. This will be connected to the Web Page that we created through the Existing Battle – Read Multistep Form URL.

o   An Edit Battle Details button for S.H.I.E.L.D. agents to edit the details of only active battles. This will be connected to the Web Page that we created through the Existing Battle – Edit Multistep Form URL. Since we do not want agents to edit the details of inactive (completed) battles, we will use FetchXML to filter out these records through the Filter Criteria area.

If you are curious about the FetchXML lines I used:


<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">

  <entity name="ap_battle">

    <attribute name="ap_battleid" />

    <attribute name="ap_name" />

    <attribute name="createdon" />

    <order attribute="ap_name" descending="false" />

    <filter type="and">

      <condition attribute="statecode" operator="ne" value="1" />




Now, we can Save & Close and start assembling back in the Design studio to see the finished product. Ensure you click Sync before you start the List assembly.


In the Active Battle Support page, we click on the List component and select our existing list called S.H.I.E.L.D. Battle Support.

We get a preview moment.

Now it is time to set up our Table Permissions.

A few points to consider here:

  • It is enough to consider these table permissions at the list level. They will “flow” through to our Multistep Forms/ steps without any additional work.

  • We must consider both Basic and Child permissions since we have lookups and subgrids all over our forms. Although the good news is you do not have to add Roles to your children, it is enough adding them to the Basic Permissions. Win!

  • To keep things simpler for our Basic Permissions, we will give Global access as Access type with Read, Update, Create, Append and Append to access. We add our Roles accordingly, e.g. for Administrators and Authenticated Users. However, please adjust to your appropriate security model. 😊

As mentioned, Basic Permissions aren’t enough. The complication comes from the fact that we have a fair few lookups and subgrids. This means we also need to set up Child Permissions for each. An example set up is here. As always, use your security model and apply the appropriate roles.

In this scenario, our ERD dictates we need five child permissions for the entities Avenger, Protected City, Villain, Currency and Battle Checklist because of the existing lookups and subgrids.

An example of a Child Permission is as following.

In our scenario, the complete list of Child Permissions looks as follows:

Let’s go ahead and click on Preview to save our changes.

The final step is to curate our two Web Pages hosting the Edit and Read Multistep Forms. Creating them through Power Pages Management just creates the shell. We still need to:

  • Add the Multistep Form

  • Add navigation buttons back to the main Active Battle Support page with the list

  • Style the page further as needed (backgrounds etc.)


To add the Multistep Form, we just add it as a component and get the below preview, for example for the Edit Multistep Form page.

We also add a button to go back to the main All Battles list page. 

Our Marvel-lous work is complete!

Peace out my geeky friends.

268 views0 comments


bottom of page