The Web Forms functionality lets you build complex multi-page, multi-entity wizard-style forms on your Power Apps Portals. And while there are a ton of options, it’s not uncommon to run into situations where you can’t do everything you want with configuration, so you might need to resort to a bit of JavaScript (and maybe even Liquid). One of those situations is if you want the source entity for the next step in your Web Form to be a record related to the entity of the current step.

Record Source Type

One of the things you need to specify when creating a Load Form or Load Tab type Web Form Step where you want to view or edit an existing record is the source of the record – in other words, how does the form know where to get the record you want to see or edit? The options include:

• Query String
• Current Portal User
• Result from Previous Step
• Record Associated to Current Portal User

If you’re building out a multi-step form that a single entity, often you’ll use the Result from Previous Step option. If you’re wanting to edit an existing record, often it will be related to the current contact, so you can use the Record Associated to Current Portal User option. But what do you do if you want the next step in your form to be the edit of a record related to the current record, if that current record isn’t the currently logged in contact?

Editing the Primary Contact after Editing an Account

For example, let’s say you are building a Partner Portal where users can manage their own Contacts and Accounts. You want to have a Web Form that lets users edit the Account details, followed by the Primary Contact of the account. You use an Entity List to display the list of Accounts, and then when clicking on the details for an Account, they are redirected to the Web Form where the first step is the edit of an Account, based on a passed-in query parameter of the Account ID. How can you make the second step the ability to edit the Primary Contact of that Account? What do you use for the Record Source Type for that Web Form Step?

It’s not the result from the previous step – that’s the Account. The Primary Contact is not directly related to the current contact, so we can’t use Record Associated to the Current Portal User. And obviously it’s not the current contact. So that leaves Query String. Somehow we’ve got to get the ID of the Primary Contact in the query string.

In this simple example, you could possibly put the ID of the Primary Contact in the query string right from the beginning (from the Entity List). However, in more complex scenarios, that might not be possible. Instead, you can use JavaScript and Liquid to add the ID on the preceding step, so that it is included when the form is submitted back to the server. As an example:

$(document).ready(function(){
	$('#liquid_form').attr('action', $('#liquid_form').attr('action')+ '&primarycontactid={{entities.account[request.params.id].primarycontactid.Id}}');
});

This code appends the ID of the Primary Contact to the action attribute of the form element (which in my case, has an ID of liquid_form). In the next Web Form Step, we can use the Query String Record Source Type, pointing at the primarycontactid parameter.

Make sure you are putting this code in the Custom JavaScript field on the Web Form Step before you want to edit the Primary Contact!