ENGINEERED CODE BLOG

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.

4 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.

      Nick

Leave a Reply

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

Contact

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.