Power Pages: Mysterious Disappearing Lookup Value When Using Custom JavaScript

Why the Default Experience Wasn’t Good Enough

Our client has a form where a user can select a single contact via a lookup. While the user does legitimately have access to thousands of contacts via Table Permissions, in the context of the form, only a few of these contact are legitimate options. Therefore, our client wanted to only present the legitimate options, instead of all of the contacts.

Power Pages does respect Related Record Filtering. That is, you can set via configuration to only show options within a lookup where there is a relationship between the table used in the lookup, and the row being show in the form. Unfortunately, in this case the logic to determine which contacts were valid options was more complicated than just a straight-forward relationship, so this wouldn’t be enough here.

So we went down the road of creating our own user experience.

Converting Lookup to Drop Down

In cases where we are creating custom user experiences for lookups, we often first convert the lookup to a drop down using Form Metadata. If we didn’t do this, the lookup control would consist of a text input, which contains the name of the selected row, and two hidden inputs, which contain the ID of the selected, and the name of the related table. Once the lookup is a drop down, the column is represented by a Select input which contains the name and ID of the row, plus the hidden input for the name of the related table.

Turning the control into a drop down makes our lives easier in situations where we are going to leverage existing JavaScript plugins that already work with the Select element, like the one used by Power Pages, Select2.

So in our case, we used FetchXML and Liquid to query the valid contacts, updated the Select to include only those options, and used Select2 to transform the Select in order to provide an experience where the user could search through options using a keyword search.

In development, everything worked great. However, once it went for testing, we started getting weird reports of it not working as expected.

Mysterious Column Clearing

The testing folks reported that, in certain cases, when the form is submitted, instead of saving the value that was selected, instead the lookup column was cleared. Sometimes it worked as expected, and in other cases, saving ended up clearing the column. Our only clue was that it was consistent based on which contact you selected.

We confirmed that the correct value was being passed back to the server. So it wasn’t an issue with our JavaScript. We also confirmed that the user had the correct permissions to related the problem contacts with the primary record. So it wasn’t a permissions problem.

After much head banging, we finally stumbled on the answer – the problem was because we converted the lookup to a drop down.

Good Old ASP.NET Web Forms

The forms technology of Power Pages was built using ASP.NET Web Forms. This is a pretty old technology, but remember that Power Pages got it start more than 15 years ago, so at the time, it was an appropriate choice.

When a lookup is converted to a drop down, under the hood the ASP.NET DropDownList control is used. For anyone that knows the page life cycle of ASP.NET Web Forms, you’ll know that first the options for the drop down are added to the control, and then, any value that is provided as part of a post back will be set as the selected item. The trick is that in order for a value to be set, that value must exist in the list of available options.

In our case, the list of possible contacts (without any filtering) was greater than 5000 rows. Power Pages will only include the first 5000 in the list, and will ignore any rows after that. The problem contacts were those that weren’t in those first 5000.

This means that when the server received the post back to save the form, it first loaded up the available options in the drop down, which are those first 5000 rows, and then it tried to set the contact to the one we provided, but it wasn’t in the list. So the value of the control ends us as null. Which then gets saved as part of the form submission, resulting in the lookup column being cleared.

The solve was simple – don’t convert the lookup to a drop down. Instead, just create our own Select using JavaScript to use with the plugin, and then fill in the Name and ID inputs of the lookup control ourselves. With this fix in place, the problem of mysteriously disappearing lookup values was solved.