Why I think you should avoid #PowerApps Portal Advanced Forms (aka Web Forms) like the plague

So yes, this is a contentious topic and there is no simple answers here. There are definitely advocates on both side of the argument.

That said, too often I see portal devs default to using Advanced Forms (formerly known as Web Forms) because they may take less initial time to set up and consideration isn’t given to overall site design and usability. So here’s my two cents on the ongoing debate!

Pitfalls of advanced forms

  • Advanced forms automatically add two un-predictable GUID parameters to the URL
    • Usability and accessibility of the portal should avoid unpredictable, or un-hackable URLs.
    • The advanced form parameters prevent a user from being able to navigate directly to a specific page without knowledge of the auto-generated GUID parameters. A page may be step x of an advanced form so only the URL params are unique (but not predictable)
  • Advanced forms sacrifice control over each page’s content
    • As an advanced form generates multiple pages, adding copy or functionality to a specific page becomes difficult or impossible and therefore often requires a significant refactoring out of the form.
    • While some work-arounds are possible (e.g. including copy in a entity metadata record, or page-level javascript) they sacrifice control and promote code smells
  • Potentially breaks back button
    • Conditional advanced form steps can break the use of the browser’s default back button on top of sacrificing URL-addressable pages

Advantages of advanced forms

  • Speed of development
    • Using a single advanced form (and single web page, web template etc.) allows for a much faster development time compared to creating multiple basic forms (aka entity forms), web pages, etc. for each page.
    • The argument is that this investment in development time is worth the effort to avoid pitfalls discussed above
  • Fewer configuration records
    • Similarly, as a multi-page advanced form only requires singular records, the management of data is easier
  • Session management
    • Perhaps the biggest advantage of advanced forms is that it provides out of the box session management.
    • If the portal presents a 10-page web form and an authenticated user closes the browser on page 4, the portal can return the user to that page on logging back in. This is the only functionality, if required by the project, that can reasonably make an argument for the use of advanced forms.
    • I do usually question this as a requirement however, preferring shorter forms and a task list pattern, potentially with a convention-based generation of tasks links (e.g. set the URL of the task based on Status Reason of the target entity).

The conditional navigation conundrum

The other consideration of course is conditional navigation. I fully accept that advanced forms make conditional navigation much easier but due to the above downsides to using them I prefer to use either control flow or convention-based statements in liquid to include the appropriate basic form.

This pattern is not usually possible if a decision on page 1 impacts which page to navigate to for page 2 but I’ve normally been able to re-arrange the order of pages to allow decision-making data to be captured earlier. As long as you have control over the design of page flow then this is usually avoidable.

Conclusion

The only advanced form functionality that cannot be replicated in basic forms, and therefore the only reason to use them, is session management.

If session management is a real requirement for the project or you need instant control over page navigation, then consider advanced forms, otherwise always default to basic forms.