Filtering Lookup by Relation in Dynamics 365 for Operations

by | Updated January 3, 2018 | Development, Dynamics 365 for Finance and Operations

Last time I showed how to add filtering capabilities to your lookup using the DataInteractorFactory class. This time I intend to show how to extend filtering capabilities to support lookups where there is more than one key field on the target table.

Let’s say we have a table, SSISplitBillingTable, that contains split billing codes for a customer. The primary key for this table would then be the combination of the SplitBillingCode and AccountNum.

Combination of SplitBillingCode and AccountNum

This also implies that each customer may have multiple SplitBillingCodes. Because we want to identify a default code for each customer, we will add a foreign key to CustTable.

Add foreign key to CustTable

And a table relation to SSISplitBillingCode to enable the lookup.

Add split billing code to lookup

When we click the drop-down to select a Split billing code from the CustTable form, we are presented with too many records. The intention is to allow the user to select only Split billing codes that are associated with the current CustTable record. As you can see, the list contains 2 records for the current customer, C0020, and one for customer AA.

split billing code associated with CustTable record

It was at this point that I must admit I was a little confused. I had assumed that if I put both fields in the table relation that my list would be properly filtered, but apparently, I would be forced to write a little code to make this work. I knew I didn’t want to add a lookup method to every form that would contain this field because that requires too many modifications and doesn’t do anything to prevent future problems. Instead, I was going to see if I could modify the DataInteractorFactory class. It was here I learned something new.

My approach was to explore the DataInteractorTarget owned by the DataInteractorFactory class. Among other things, this class identifies the field, control, and table relation involved in the lookup. A little investigation led me to the BoundRelation class, and the realization that my scenario was already supported.

Inside the applyFieldDependenciesToQuery method, the BoundRelation class sets up the query used to perform the lookup. It does this by iterating through the collection of dependent fields, adding each field value as a range on the query. The problem was that my dependent fields collection was empty. The reason the collection was empty could be found in the processDictRelation method. This method iterates over the lines in the table relation until it finds the primary key field. Each field it encounters before it is found is added to the dependent field list.


This means that to filter our lookup to only those records with a matching AccountNum, we need only reorder the lines in our table relation.


Now when we use the lookup the results are properly filtered.


Related Posts


  1. Denis

    the first question when you show this to user or consultant will be to remove account Id field (or at least change its position) – first field in lookup should be what we are selecting. did you find the way to achieve this without programming?

  2. Brandon Carmichael

    Hello Denis:

    After talking with Mark, he did not find a way to achieve this without programming. That said, not sure if this is or is not possible without programming – it was never our goal to achieve this without programming.


  3. DP

    Hi ,
    I need to lookup the cost center dimension values in string edit control in a new table in D365 for operations
    Any ideas how to do ?

  4. Brandon Carmichael

    Hello DP,

    Thanks for reading and for the comment. Unfortunately we’ve not had a need for that type of lookup, so I don’t have a short answer for you without putting some hours into testing. It sounds like a great future blog post!


Submit a Comment

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

Upcoming Events


02jun2:00 pm2:30 pmBusiness Intelligence for Batch Manufacturers

16jun10:00 am10:30 amHow AP automation can speed up month-end close in D365 Finance

17jun11:00 am12:00 pmConfab Live with Stoneridge – Real Time Marketing Strategies for Success

23jun10:00 am10:30 amThe Modern Manufacturer: Cost Accounting in D365

30jun10:00 am10:30 amAP Automation Checklist for a 2022 Rebound

30jun2:00 pm2:30 pmAchieving Success: How Technology Is Helping Nonprofits Thrive


01jul11:00 am12:00 pmConfab Live with Stoneridge – Dataverse Virtual Entities

14jul12:00 pm12:30 pmBeyond Reporting - What Business Intelligence Can Do For Your Agribusiness

14jul2:00 pm3:00 pmMastering the Production Floor

15jul11:00 am12:00 pmConfab Live with Stoneridge – Integration Strategies for End User Success

21jul10:00 am10:30 amThe Modern Manufacturer: Manufacturing Software in the Real World

21jul12:00 pm1:00 pmIs it Worth it to Upgrade to Dynamics 365 Finance and Supply Chain Management? - Everything AX Users Need to Consider

28jul2:00 pm2:30 pmConsiderations for Successful Testing Plans for Major Releases of Dynamics 365 Finance and Supply Chain Management

About Stoneridge
Stoneridge Software is a unique Microsoft Gold Partner, with emphasis on partner. With specialties in Microsoft Dynamics 365, Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP and Microsoft Dynamics CRM, we focus on attracting the most knowledgeable experts in the field to our team, and prioritize delivering stellar solutions with maximum impact for your business. At Stoneridge, we are deeply committed to your results. Each engagement is met with a dedicated team, ready to provide thorough, tailored, and expert service. Based in Minnesota, we intentionally “step into your shoes,” wherever you are. We focus on what you care about, and develop trusting, long-term relationships with our clients.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!