Testing a polymorphic lookup

There are polymorphic lookups now, but what’s the big deal? Well, I don’t have to go far to find an example of where it might be helpful. Here is a screenshot from the actual model-driven form on one of the projects I’ve been working on:

There are 3 different lookups on that screen, yet only one of them is supposed to be populated. Which means there are business rules involved, possibly validations, etc. I could simplify the screen above and get rid of those business rules right away by adding a polymorphic lookup – that would be a single lookup which would reference either of those three referenced tables.

As of today, polymorphic lookups can only be created through the API, and the link I put right at the top of this post provides all the required details. Except that… there is an error in the json source:

Heh… they had to make a mistake somewhere, or I’d really have to start worshipping the product team for the goodies they are delivering

Anyways, to create a polymorphic lookup we need something to send an HTTP POST request to Dataverse, so I used Restman for that:

https://chrome.google.com/webstore/detail/restman/ihgpcfpkpmdcghlnaofdmjkoemnlijdi?hl=en

Here is how the whole thing looks like, and I’ll provide the json I used below:

And here is the json:

{
 "OneToManyRelationships": [
   {
     "SchemaName": "new_test_contact",
     "ReferencedEntity": "contact",
     "ReferencingEntity": "new_test"
   },
   {
     "SchemaName": "new_test_account",
     "ReferencedEntity": "account",
     "ReferencingEntity": "new_test"
   },
   {
     "SchemaName": "new_test_systeuser",
     "ReferencedEntity": "systemuser",
     "ReferencingEntity": "new_test",
	 "CascadeConfiguration": {  
        "Assign": "NoCascade",  
        "Delete": "RemoveLink",  
        "Merge": "NoCascade",  
        "Reparent": "NoCascade",  
        "Share": "NoCascade",  
        "Unshare": "NoCascade"  
     }
   }
 ],

 "Lookup": {
   "AttributeType": "Lookup",
   "AttributeTypeName": {
     "Value": "LookupType"
   },

   "Description": {
     "@odata.type": "Microsoft.Dynamics.CRM.Label",
     "LocalizedLabels": [
       {
         "@odata.type": "Microsoft.Dynamics.CRM.LocalizedLabel",
         "Label": "Test Client",
         "LanguageCode": 1033
       }
     ],

     "UserLocalizedLabel": {
       "@odata.type": "Microsoft.Dynamics.CRM.LocalizedLabel",
       "Label": " Test Client",
       "LanguageCode": 1033
     }
   },

   "DisplayName": {
     "@odata.type": "Microsoft.Dynamics.CRM.Label",
     "LocalizedLabels": [
       {
         "@odata.type": "Microsoft.Dynamics.CRM.LocalizedLabel",
         "Label": "TestClientLookup",
         "LanguageCode": 1033
       }
     ],

     "UserLocalizedLabel": {
       "@odata.type": "Microsoft.Dynamics.CRM.LocalizedLabel",
       "Label": "TestClientLookup",
       "LanguageCode": 1033
     }
   },

   "SchemaName": "new_TestClientLookup",
   "@odata.type": "Microsoft.Dynamics.CRM.ComplexLookupAttributeMetadata"
 }
}

With that, I now have my lookup field added to the new_test table:

Although, it does not look quite right there, since, it seems, I can only see one related table in the designer. But, well, that’s only a preview after all, and that seems to be just a minor inconvenience.

Once this new field is added to the form, I can use records from either of the 3 referenced tables to populated the lookup:

Now, here is what I was interested in beyond the fact that we can reference multiple tables. What happens on the TDS endpoint side? Since this is what I’d be using for Power BI paginated reports. And, actually, it’s all good there. Here is an example:

So, basically, TDS endpoint will give us three columns for this kind of lookups. The first column would provide referenced record guid, the second one would provide referenced record type, and, finally, the third one would provide referenced record “name”. Which is more than enough to do proper reporting in Power BI/SSRS.

And what about the advanced find?

It’s interesting there, since, when specifying filtering conditions, I can see combined list of possible operators. For example, on the screenshot below, I’ve selected “Equals Current User” (and this is a polymorphic lookup, so I could have selected “Equals” and pick an account instead):

Still, if I used “Equals” condition, I could pick from either of the three referenced tables:

Well, that’s some cool stuff from the product team, and the only question for me is whether it’s something I should start using in production? Or if I should wait till this is out of preview? Holding off for now, but this is really testing my patience