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.
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:
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?
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!
[…] post Power Apps Portals: Related Entity as Source of Next Web Form Step appeared first on Engineered […]
I was looking for the same kind of solution. Thanks Nicholas for sharing this useful information.
Thanks for this post – timing was perfect.
Imagine we wanted to pass the current record ID as a query string parameter: how would this be done without using JavaScript? i.e. without using the below:
$(‘#EntityFormView_EntityID’).val()
Unfortunately I don’t know an easy way with Liquid. One work around is to access the ID in JS, then pass that ID to a Liquid JSON web service page via query string, then you can retrieve data that you need. I agree though – not ideal.
Nick
How about if we need to pass record id from Insert form to another insert form?
Hmm, good question. I’m not sure how to do that. The only thing that comes to mind is to have a step in between the inserts that is an edit of the first record, so you can get the ID, so you can then pass it to the next step using this technique. Not a very good user experience though.
Nick
Just brilliant. That’s exactly what I needed, to be able to add custom querystring params to next submit page
Right now I have a multiple step advanced form im loading from tabs and i need to grab one of the fields from step 1 and just add it to an alert for the 4th step just for testing purposes. Once i get this going then i could take those values and use them to call a web service.
Are all steps on the same table/entity? If so, you can use Liquid to get data from the current row.
Nick
Hello Nicholas,
Thanks for this post. I have a Many-to-Many relationship between Contacts and Accounts using a joiner table called Individual Role where I store the role a user has to an account. On that table I have a list/view (has contacts and account as lookup field) and I want the user to be able to edit the account record from the list when they press on a record action button. Is there a way to pass the accountid following your steps?
Do you want the edit experience in a modal, or on a separate page?
One possible option would be to use JavaScript to create a custom action button. Using Liquid or Web API it would be simple to get the ID of the related account.
If you want a modal, the JavaScript it a bit more complicated – you essentially have to recreate the code that the product uses to pop open the modal (it displays the form in an IFRAME). If you are ok with going to another page, then you just need to craft the correct URL with the ID of the account.
You might also be able to put in a “placeholder” action button, which would normally be an edit on the Individual Role table, and then use JS to update that button to instead point at the correct form and row.
Nick
[…] there was a comment on my blog Power Apps Portals: Related Entity as Source of Next Web Form Step about adding a custom Edit button to a list or subgrid. In this case, rather than editing the main […]
Hi, is there a way to update this param on change event? Trying to append a lookup filed value, that can be changed.
Yes, instead of the JavaScript being on the document.ready, put it in the change event handler for the lookup field. You’ll need to update the JavaScript to handle the fact that the lookup could change multiple times (so instead of always appending another query string parameter to the action, you’ll need to check if the action already has the query string parameter, and if so, update it). But that should work.
Nick
Hi Nicholas, thank you for the post! I think the solution of what you are describing is what I need, but I also don’t think I understood the solution 100%.
Currently, I have two tables: applications and EV questions. Each EV questions row has a field called related application so it can be linked to each application for some business logic and data structure reason. The first few steps of the multistep form are forms from the applications table. and then it’s followed by forms from EV questions table. The problem is I cannot find ways to inject the application row id into the related application of the EV questions table. My understanding is your solution applies to my situation.
Should I put the JS in the last Application table related step to pass the ID? but how do I retrieve it from the EV question form, that is the next step?
Thank you 🙂
This blog post describes kind of the opposite of what you’re looking for. The situation in the blog post is if you started with an EV question, and then wanted a step after that to be the application.
In your case, if an application has many EV questions, which question is show first after the application forms are done?
Nick
Yes, application is shown before EV questions. I have been trying to find ways to map a row of application to a row of EV questions. Been searching for days and still can’t find anything 🥺 Thank you Nick!
If there are many questions, I would recommend that once you gathered the details about the application, the next step is still on the application, but shows a subgrid of related questions. Then the user can open up each question in the subgrid and fill out those forms.
Nick