Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse


Power Apps Portals: Web Forms with Complex Conditions

It’s been too long since I’ve posted! With all of the virtual conferences taking place in 2020, I couldn’t find the time to get any blog posts done. But I plan to change that in 2021. First off, I want to share a solution for when you want to use the Condition type of Web Form Steps, but your condition is more complicated than just checking if a regular field equals a specific value.

Conditional Web Form Steps

Web Forms allow you to build multi-page wizard-style forms in Power Apps Portals. The simplest web forms follow a single path through the wizard, where only one other step can possibly follow each step. However, in more complex scenarios, you may want to have different paths through the wizard depending on what has been entered in previous steps.

One situation where we’ve used Web Forms is to build out registration for the portal. In one case users were able to request an invitation code by entering their membership number. We built out a web form where the first step asked the user for their membership number. We wanted the next step to work differently depending on whether the user entered a valid membership number or not.

The syntax for creating the conditional expression does not allow for complex operations like “check if this value exists in another entity”. The conditional logic can really only check to see if a column (field) of the row (record) from the previous step equals a specific value. So how can we accomplish our goal? By using synchronous plugins or workflows.

Synchronous Workflows or Plugins

The conditional expression is evaluated after the data from the previous step is saved to Dataverse. In our case, a Portal Invitation Request row was being inserted by the first step. We then created a synchronous plugin that fires on the create of Portal Invitation Request row that took in the submitted membership number, performed the query to determine if it was a valid number or not, and updated another column we had created with the result of that operation. We could then use the value in that other column in our condition. Since the plugin was registered to run synchronously this all happened before the conditional expression was evaluated.

Here is an example of what the plugin might look like:

public void Execute(IServiceProvider serviceProvider)
   var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
   var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
   var service = serviceFactory.CreateOrganizationService(context.UserId);
   var dataContext = new OrganizationServiceContext(service);

   var portalInvitationEntity = context.InputParameters["Target"] as Entity;
   var membershipNumber = portalInvitationEntity.GetAttributeValue("nh_membershipnumber");

   portalInvitationEntity["nh_membershipnumberfound"] = dataContext.CreateQuery("account").FirstOrDefault(a => a.GetAttributeValue("nh_membershipnumber") == membershipNumber) != null;

In this case the plugin is registered on the create of Portal Invitation Request rows. We retrieve the nh_membershipnumber from the Portal Invitation Request that was just created (which is what the user has filled in on the first step of the web form). Next, we query to see if there are any Account rows that match that membership number – if yes, we set the nh_membershipnumberfound field on the Portal Invitation Request to true, otherwise we set it to false.

Once we’ve got that plugin registered we can use the following conditional expression in our web form step:

nh_membershipnumberfound = true

If your complex logic can be performed using classic workflows you could use those instead of a plugin (or, use a custom workflow activity if you need to invoke your own custom code). Just be sure to make it run synchronously.

Unfortunately Power Automate is not really any help in this situation, since those flows run asynchronously. This means that by the time the logic runs, the conditional expression has already been evaluated.

10 responses to “Power Apps Portals: Web Forms with Complex Conditions”

  1. […] post Power Apps Portals: Web Forms with Complex Conditions appeared first on Engineered […]

  2. Ryan Spain says:

    Excellent solution to a problem I’m sure many (including myself) have encountered.

  3. Franco Musso says:

    Cool solution, thanks for sharing 🙂
    For those of us that don’t have the option / skill to use a plugin, maybe give fetch XML and liquid a try on the subsequent step, searching memberships for that membership number… then maybe show / hide form sections if no match is found? Definitely not as elegant as your solution but seems feasible for us low-coders (the irony being your pro-code solution involves fewer lines of code!)

    • Nicholas Hayduk says:

      Yup, that could work, but that would require global read permissions on the membership table, which I like to avoid if at all possible.


  4. Hi Nicholas,
    Somehow, I always end up in one of your posts when doing my google/bing searches on portal topic. Great compliment for that !!!

    Is the above approach still the best way? Or can we do similar things (better) with the webapi functionality?

    • Nicholas Hayduk says:

      You could do similar things with Web API, however it would depend on the situation. For example, if your step creates a record, the Web API won’t help because the record doesn’t exist yet.

      So for some situations, the Web API might be easier than creating a plugin, but it won’t always be the solution.


  5. Ole Einar Marken says:

    Hi Nick!

    Just to be sure: “The conditional logic can really only check to see if a column (field) of the row (record) from the previous step equals a specific value.”

    So that means I can’t check for a condition on a step longer back than just one?

    Example: On step 5 I can check data input from step 4, but not from step 1?

    (That would explain a proplem I ran into.)


    • Nicholas Hayduk says:

      Yes, I believe that is the case. The syntax only allows for column names, so there is no ability to tell it to look further back in the process.


  6. ines says:

    hello I hope you are well I have a question regarding PowerPages how to manage the visibility of fields by type of person if for example I have a dataverse ‘users’ table with an ‘access_rights’ column. suppose that in a page I have a table and a powerbi how to make the visible of the powerbi have the value ‘access_rights’= ‘client general user’ || ‘dev general user’ and the table will be displayed if ‘access_rights’=’client admin’ || ‘dev admin’ on powerapps I can do it but on powerpages I can’t i know that in pages we have permission (admin , anonymous users, authenticated user) but in my case I have several types of users in the ‘access_rights’ column of the users table I hope you can help me.

    • Nicholas Hayduk says:

      On Power Pages, the “users” are actually contacts. Do you have the access_rights column on the Contact table?

      If so, I’d normally use Liquid code to retrieve the value of the access_rights column and then conditionally show the right parts of the page depending on their rights.


Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.