Dynamics 365 Connector – Cosmans' Dynamics 365 blog

June 28, 2018

Understanding the Dynamics 365 List Records connector retrieve limit

Hello;

Let’s talk about the retrieve limit of the Dynamics 365 connector that is used in Power Apps, Logic Apps, and Flow. While working with a large data set we noticed that the maximum amount of records per request is 512.

While looking at the settings we found the pagination setting and the ability to set an upper limit of query. Both of these made me research this a bit more and I found that tese settings were implemented back in August of 2017 with the original post found at: https://flow.microsoft.com/en-us/blog/four-connector-action-settings/. It’s worth noting that the settings options have changed since then but this is where the pagination functionality was introduced.

Looking at the List Records (Previews) connectors settings today; it looks like this:
Dynamics List Records

The pagination is pretty straight forward it allows the connector to continue to make requests to get your full data set. Currently I have an outstanding question if each page counts as a individual execution; if it does this means that there is a cost associated with each page. Once I have an answer I’ll make sure to update this.

The Limit option allows us to specific our ceiling regardless of how many pages it goes through. I really think that if your going to be using a LogicApp or Flow to retrieve and update Dynamics 365 data that you have a good idea of how much traffic each action is expected to have. With this in mind I think its a best practice to understand and set a limit option on any List Records connectors if your going to enable pagination.

Hope this sparks some good conversation as these options were implemented in a simple way to use; which I really appreciate.

June 27, 2018

Understanding the Expand Query in the Dynamics 365 List Records connector – Part 2

Hello;

Part one of this post (Understanding the Expand Query in the Dynamics 365 List Records connector) showed how to utilize the expand query paramete. This post will covering actually using these values to update an account with the data. Let’s dive right into part two of using the expand query in the Dynamics 365 connector that is used in Power Apps, Logic Apps, and Flow.

We left off with our related primarycontactid data returned from our account request.

Since we have our data the next thing is to take action on these returned records. We’re going to add an Apply to each as the next step. We’ll add the value from dynamic content. This will be each record returned from the Account Query. We will want to choose an action. In this case we’re going to use the Data Operations – Parse JSON. Let’s go ahead and select this action.

The Parse JSON action allows us to specify which returned field to parse on. This is an important step to get correct. Using the Dynamic Content you can search and select the Primary Contact item. The next step is critical; hovering over it to ensure it has the right field name(see expand query field for the proper name); in our case it’s “primarycontactid”. This is critical step as its very easy to get the wrong field here.

Using the Parse JSON it’s required to enter the schema; luckily it allows us to paste data and it’ll generate this for us. In this case I’ve simply used the data returned for my account from the previous post.

The generated schema comes out like the following.

{
    "type": "object",
    "properties": {
        "@@odata.type": {
            "type": "string"
        },
        "fullname": {
            "type": "string"
        },
        "firstname": {
            "type": "string"
        },
        "lastname": {
            "type": "string"
        }
    }
}

Now that the schema is completed; we’re now able to use this transformed data dynamically. We’re going to update the account name to include the contact full name. Adding a Dynamics 365 – Update record action is the first step. When clicking into any field you can now see the dynamic data of both the Parse JSON result and List Records(Previous) aka the account data.

The flow is now completed. Let’s execute this and double check within CRM to see if it updated properly. We can see the results of the update step.

After double checking CRM to see our record updated I think we can call this a wrap.

We’ve went through parsing the expanded query results and turning them into Dynamic Content to be used. There are a ton of other things that can be done with the different actions and conditions; but this is a basic example of how to use the Expand Query field in the connectors.

I hope you’ve found this helpful.!

June 25, 2018

Understanding the Expand Query in the Dynamics 365 List Records connector

Hello;

Recently I’ve been diving deeply into the Dynamics 365 connector that is used in Power Apps, Logic Apps, and Flow. I’ve found the documentation lacking when trying to do more advanced features. Today were discussing the Expand Query component of this connector.

First lets start with a new flow and add the Dynamics 365 – List Records(preview) connector.

Once we have the connector added we’re going to retrieve all Accounts. We select an organization and then select which entity we’re going to use. This will get us all accounts in the organization.

The Expand Query option is where we’re going to focus on. MSDN documents this field here. The documentation states:

Expand Query
string
Related entries to include with requested entries (default = none)
Key:
$expand

This doesn’t really give us a practical example to work from. When researching online the majority of searches come back with using the relationship name of a relationship. This is actually incorrect. Let’s take the Primary Contact relationship on the Account entity as an example.

For the Expand Query field it actually takes the lookup value of this relationship. In this case it is looking for the “primarycontactid”.

Let’s go back to our query and add this in.

As you can see we’re able to specify the lookup field and then select exactly which columns to be retrieved from the Contact entity. The output of this query returns the related record in a json object.

      "primarycontactid": {
        "@odata.type": "#Microsoft.Azure.Connectors.Crm.SubItem",
        "fullname": "Jason Cosman",
        "firstname": "Jason",
        "lastname": "Cosman"
      }

Getting the related record is only half the battle as it isn’t able to be used as dynamic content yet. You have to parse it out and then use it. Stay tuned for the next post where we update the account with contact information using the retrieved data.