The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
‘Better Together’ Integration forum available
We're launching a how-to forum where you can learn and engage about how Dynamics 365 integrates with other Power Platform products.
Read about Better Together forum
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
The power of Entity Forms in Power Apps Portals is that they mirror much of the functionality available in model-driven apps (and Dynamics 365). While the parity isn’t 100%, one advanced feature that Entity Forms does support is Related Records Filtering on lookups, where the available options in the lookup are filtered by some other data that has already been selected. However, in certain cases, this functionality doesn’t offer exact parity out-of-the-box – one of those cases is when you are creating a new record via a subgrid, and you’re expecting that the parent record is used in the filtering of the lookup.
The Related Records Filtering functionality on lookups allows you to limit the available records that can be selected for a lookup, based on another value on the form.
This technique is used quite a bit in the Portal Administration model-driven app, to limit the records that are available to only those associated to the current website. So, for example, when creating a Web Page, once you select the Website record, the options for lookups like Parent Page and Page Template will only display records that are also associated to that Website (on top of the filtering of the view defined as part of the lookup). This prevents you from mixing records between websites, which would leave your portal in an invalid state.
As I mentioned above, Power Apps Portals supports this functionality when you expose lookups via Entity Forms – in addition to filtering provided by both Entity Permissions and any filtering included as part of the view used to show lookup options. However, because of a difference in how fields are set when creating related record from a subgrid, it doesn’t always work the same was as in a model-driven app.
When you create a record from a subgrid in a model-driven app, the lookup for that particular relationship is automatically populated with the record that the subgrid was on. In Power Apps Portals, it doesn’t quite work the same way. While if you create the record from a subgrid, the record will be associated with the parent (I’ll use the term “parent” for the record that appears in the lookup, although it doesn’t necessarily need to be a parental-type relationship, just 1:N), this only occurs as part of the save – if you include the lookup on the form it will be blank. Because this value is blank, the value of the parent record is not taken into consideration when it comes to related record filtering. Only after the record is saved is the relationship populated.
In order to get the related records filtering to work as expected on create, we need to get that field populated on the form.
If the value of the parent record is set until the record is saved, how does the Portal code know what to set it to? The answer is that the ID of the parent record is passed in the query string. This is obvious when you choose the Web Page Target Type for the subgrid Create action, as you can see the query string parameter in the URL. What some people don’t realize is that when you choose the Entity Form Target Type, the form is rendered as an IFrame, and the same query string parameters are passed. The ID of the parent record is passed via the refid query string parameter.
Since we have the ID of the parent, we can use that to prepopulate the lookup, which then will apply the filtering to other lookups.
As an example, let’s say you have a custom entity called Projects, which has a lookup to both Account and Contact. Users are able to create new Project records from a subgrid on the Account record. When selecting a Contact record on a new Project created from an Account, we only want to see Contacts related to the Account.
This can be achieved by:
Replace new_lookupattribute with the name of the lookup to the parent record.
This code uses the refid query string parameter to set the value of the read-only lookup. Once set, it will be factored into the related record filtering on the Contact lookup.
The code also hides the read-only lookup, as the user doesn’t need to see the field.
This technique can also be used to filter based on fields on the parent record, and not just the parent record itself. For example, let’s say there was a lookup to language on the Account record, and you only wanted to show Contacts whose primary language matched that lookup. Using ID of the record (from the query string) and Liquid, you can get that value from the parent record, set it in a lookup, similar to above. As an example:
The post Power Apps Portals: Related Records Filtering on Lookups When Creating Records via Subgrid appeared first on Engineered Code.
Business Applications communities