Currently when adding values to a lookup control, there are certain capabilities that allow us to find the records that we are looking for. These capabilities include searching for a record by text and changing the view. We also have the ability to create a new record which will open up the quick create form if available.

The image below shows the current layout of the Lookup controls prior to Wave 2.

When you open a similar record in Wave 2, initially it seems like this behavior is the same, but you will notice that the Change View has been replaced by Advanced Lookup. See image below:

So, what is this mysterious Advanced Lookup? The Advanced Lookup will open up a dialog that will display the full view of all the fields that make up the Lookup view for the table that we are triggering. We still have the ability to search in this new popup window, change the view, and every time that the view is changed, we will see the full list of columns in the view (not like we are seeing in the lookup control itself). We are able to select the record that we want, click on Done and get it populated in the Lookup control.

If you click on the link of a particular it will open up that record on a dialog above, so that you can see additional data before selecting the actual record.

Earlier this year, Microsoft introduced polymorphics relationships or multi-table lookups. What this means is that we can have a single lookup control that will provide us the ability of having a data source of multiple tables and not just one (similar to activities, but not multiselect).

There are several ways to create Polymorphic Lookup controls, but probably the easiest way is to do it using the XrmToolBox Polymorphic Lookup Manager plugin. You select the solution and table, add the name of the lookup and then select the entity relationships that are required for this new control.

The image below shows this in XrmToolBox.

Once you have configured your settings, just click on the Create Polymorphic Lookup button, and this will create the new attribute for you. This process can take 15-30 seconds.

If you navigate back to your solution explorer, you will notice that the control is created, but it will not show that the control is a Polymorphic Lookup control, but just a lookup control, and in the related table area it will only show a single related table. Probably something that will be addressed in a later release. The image below shows how this looks in the maker portal.

Now that the control has been created we will go ahead and add it to the form. This is just like any other control that you add to the form. There is no special configuration that is required for this.

In the case below, I created 3 tables to store the manufacturer of a vehicle (Motorcycle Manufacturer, Car Manufacturer and Aircraft Manufacturer). Once I put the control on the form. And click on the search icon on the control, I will see the results from all of the related entities in a single search results, as shown below. You can filter this by record type, by clicking on the link next to Results from, which shows three types of records.

Finally, when we click on the Advanced Lookup link on the polymorphic lookup control, we will get an additional area on the left hand side of the dialog, where we can select which table we want to filter and select the record from. Switching for one option to another will show us different results, but only a single record can be selected. The Add new option on the top right, will now have a drop down next to it, so that if we need to add a new record, we can add the record to the correct table that we want. The image below shows the Advanced Lookup dialog for the Polymorphic Lookup control.

Additional posts related to the Dynamics 365 and Power Platform 2021 Release Wave 2 will be posted by following the link below:

Power Platform 2021 Wave 2 Release Posts

The post Power Platform 2021 Release Wave 2 Unified Interface Updates – Advanced Lookup appeared first on Aric Levin's Digital Transformation Blog.

In order to get started, the first thing that has to be done is enabling the Endpoint, so that we can create a connection from SQL Server Management Studio (SSMS) to our Dynamics/CDS environment. As of now, there are two ways to enable this endpoint.

The first is by navigating to our environment in the Power Platform Admin Center. Click on the settings in the Command bar for the environment, expand the Product collapsed section and click on Features. On the features page change the toggle for TDS endpoint from Off to On.

The other way to get the same results is by using the SQL 4 CDS Plugin for XrmToolBox by Mark Carrington (make sure that you have the latest version). Open the Plugin and connect to your environment. In the Object Explorer pane, under entities, you will see the T-SQL Endpoint tree option.

Right click on the T-SQL Endoint (Disabled), and select Enable:

Making this change will allow you to make connections to your CDS environment using the new T-SQL endpoint.

The next thing is we need to connect using SQL Server Management Studio. I am using SQL v18.5, but you should be able to use it with some of the prior versions. The main thing is how we connect to our cloud database.

Within your SSMS, in Object Explorer, click on Connect and select Database Engine. This will pop up the Connect to Server window. In the Server name, enter the Organization Name following by the region and the port. The format would be as follows:
orgname.crm{region}.dynamics.com,5558

If your organization name is crmdemo and your are in North America, the Server name would be: crmdemo.crm.dynamics.com,5558

Next, we have to provide the authentication method. Based on your connection there might be a few different options for you to use. You will need to choose one of the three Azure Active Directory Authentication methods based on your connection settings.

I have tested this out with both Azure Active Directory – Password, which is used when you are connecting using a Username (email) and Password as well Azure Active Directory – Universal with MFA, which will user your organization’s MFA settings to connect.

In this post, I will be using the Azure Active Directory – Password. If you are the only one using the computer, you can check the Remember Password. The screen below (with a few blurs), shows how the connection dialog will look like.

Finally, our Object Explorer can be expanded, and we will be able to see all of the available tables that we can query on. The image below shows a partial list of the tables that are available:

A few things to note.

• This is still in preview and not available in all regions
• The database is in Read-Only state, so no updates can be performed (I am not sure if and when that will change)
• Only tables and table columns are provided, but there are no custom views or stored procedures. The tables also display the name attributes from related entities.
• Although what we are seeing in our database shows under tables, these are actually the filtered views.
• The supported SQL operations include: Batch operations, SELECT, aggregation functions, UNIONs, JOINs and Filtering

Finally, I tested a few queries out including JOIN and Filtering options and got the results just as expected. You can see the screenshot below.

Hopefully you are excited about this great new enhancement.

The post T-SQL Endpoint for Common Data Service appeared first on Aric Levin's Digital Transformation Blog.

The issue that we had was that we could retrieve each list of cases individually, but the result could be duplicate where a case could be associated with both a Case Contact and an Account Contact.

We were struggling on whether to retrieve the first fetch, and then the second fetch and check the values that were part of the second fetch didn’t appear in the list of first fetches, or the alternative was to have a single fetch Xml that contained both conditions with an Or Condition in-between. The issue here is that advanced find does not allow created an Or condition with related entities.

Thanks to a post by Alex Shlega, we were able to do this easily. This can be done using XRMToolbox Fetch Xml Builder or just writing the Fetch Directly in a Text editing tool. The end result that we had was the following:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true" >
  <entity name="incident" >
    <attribute name="incidentid" />
    <attribute name="title" />
    <attribute name="customerid" />
    <attribute name="xrm_businessname" />
    <attribute name="statecode" />
    <attribute name="statuscode" />
    <filter type="or" >
      <condition entityname="ad" attribute="xrm_contactid" operator="eq" value="{{user.id}}" />
      <condition entityname="ab" attribute="xrm_contactid" operator="eq" value="{{user.id}}" />
    </filter>
    <link-entity name="account" from="accountid" to="customerid" link-type="outer" alias="ac" >
      <link-entity name="xrm_accountcontact" from="xrm_accountid" to="accountid" link-type="outer" alias="ad" >
      </link-entity>
    </link-entity>
    <link-entity name="xrm_casecontact" from="xrm_caseid" to="incidentid" link-type="outer" alias="ab" />
  </entity>
</fetch>

By adding the entity names to the Or Filter, we are able to specify conditions for the linked entities, and by doing this filter multiple linked entities with an Or Condition.

This resolves the issue of having to deal with duplicates in the results or having multiple result sets from separate Xml statements.

The post Multiple Fetch Xml Statements with Or Filter in Portal Web Template appeared first on Aric Levin's Digital Transformation Blog.