Having worked with portals for a very long time now there is always a way to get something done even in a world where you can’t access the portal code. Be it with some JavaScript, hidden iFrame or the companion app approach. It’s great because it can get you to a solution for the business requirement but how maintainable/serviceable is it, what is the time investment that it takes you to get there and what happens when a new feature comes out that makes it obsolete. For this I would like to explore some problems related to complex forms that myself and many others have solved with other techniques but would be much better implemented directly in the portals product.
Web Forms, one of the intake engines of the portal. Actually was developed before entity forms (the other intake method). Back in the early ADX days if you needed a single page form you just created a 1 step web form because there was no such thing as entity forms. Well because Web Forms had a lot of configuration overhead and the steps were complex to link, entity forms were born to simplify the configuration for portal forms. A large percent of forms were just single page forms as well so why use this really complex configuration for what should be simple.
But there are needs for complex forms, multi-step process, conditional branching as you enter information in steps, and even linked forms. All of that is possible with the Web Form functionality of portals, but its kind of been forgotten and not loved for years now. There is a bunch of things that are needed to bring Web Forms up to par, and then take them to the next level to allow the portals to truly be a complex form intake engine.
Web Form Step Type Load Web Template
This is my number 1 item and likely easy to knock off as a feature. Load any web template as a step. The Web Form Step has a Load User Control (ASCX) step type but that is from the days when you could write your own code into the master portal template.
Load Web Template would open up a crazy world of possibilities especially with CRUD operations coming. Want a blob of HTML content, maybe a terms and conditions or an instructional bit of text as a step then use a Web Template. Want to create a summary step with read-only entity forms across 5 different entities then use a Web Template. Want to load something from another API or inject a React component, then use a Web Template. I could go on and on with the doors this would open.
The Hack: Yes there are somewhat ugly ways around to do this. Create a step of load form to a random entity, have some JavaScript that hides the form, and makes an API call to get a Web Templates HTML and inject. Works but gross and not maintainable or friendly.
Navigate Web Form Steps Out of Order
Many intake forms you don’t have to do the steps in order. Users sometimes actually prefer to do the steps of a complex form in what makes sense to them and actually want to bounce between steps as they do the form. There is a way to display a list of the steps in a form but it is just a list of view only, you can’t use them to navigate.
What if you could enable the steps to be clickable and do them however you please. If you look through complex application forms or government forms this is pretty common.
It would be great if the option to lock steps that you had to be to them in order before you could navigate at any time also existed.
Potential issues:
- Saving in progress forms on a step without completing the required fields.
The validator for required fields would need to only be enabled on a submit of that step instead of just a save or navigate away as an option. There would be the expectation that as you fill a step and then navigate to another that you are warned or your progress saved. - Conditional branching that adds or removes steps.
The step visualization somewhat already takes care of this though.
Fight the power, do step 8 of 9 first and 1 of 9 last.
The Hack: Manipulate the Web Form Session entity with an outside API call.
Web Form Step Pre-Requisites and Completion Conditions
This is probably really two features but I have it as one idea.
Pre-requisite conditions is desired when you have complex scenarios, even more so when you also pair it with the navigation of steps out of order. Let’s say you have step A, B, C, and X. You can’t view X without first completing A, B, C. Step X is actually summarizing A, B, C to you for confirmation.
Completion conditions, you might be thinking fill in the required fields. Yes that part exists but what about a step that has just a sub grid on it? What if I need X records in a sub grid. Or I have a series of fields on a form and I need a calculated field to sum them up and the sum must be more than X. Yes you could do these with plugins or JavaScript but again, citizen developer, they want something easy, configurable and maintainable. The UX for plugin exceptions in the portal is not great at all.
The Hack: Plugins and JavaScript forever.
Web Form Step Source Type Previous Step Record Entity Reference
This one is probably super common. You have an edit process, you want the user to edit an account and then the primary contact for that account as step 2. You start to make step 2 but when you go to say what is the source of your contact entity record the result of last step is actually an account and there is no way to reference the contact on that account as your step source.
If the result of previous as the source type was expanded to support record OR entity reference and then lookup the relationship you wanted as the source.
The Hack: On submit function of previous step using JavaScript lookup the ID of the entity reference, add a query string parameter of the record ID for the reference and then on the next step the source as query string.
Web Form Step Visualizer
One of the major reasons why Web Forms have fallen behind is the complexity of setting them up and managing them. It is just not easy with the relationship structure and the model-driven Portal Management app. Linking steps is hard, requires a lot of back and forth navigation and then making a change to re-order steps is a huge pain.
If the steps could be visualized in a flow type of nature then it would be a lot easier to at least understand the Web Form and how it operates. If you could manage steps with that visualization, click and drag re-order them, see the conditional branching and even create new steps then it would make them so much more approachable and easy to manage.
This one is a long term ask @Nick Doelman has requested this tool from @James Novak on XrmToolbox for a long time. I think the struggle of no one biting this off yet in the community is the complexity of the visualization and the concern that once someone does then Microsoft will put out there’s 😜. There is great potential for this with the new Portals Maker Studio to provide an experience, or a canvas app or a PCF control.
The Hack: There isn’t one at this time.
Those are the top ones on my list, I am sure there are more that everyone else out there has. If there are, please post them as ideas on the Power Apps Ideas forums and tag them as portal. The portal team looks at that board and uses it as an influence to what they are going to prioritize for releases. Feel free to send your ideas my way in the comments or on Twitter and I will happily promote them as well.
Web Forms are a huge feature that is necessary for complex intake of information and we need to get them more rich with improvements and new features so that they are better adopted. Please go vote for these ideas!
Colin Vermander 
One thought on “Power Apps Portals Web Form Ideas, Desired Improvements”