Connect to Microsoft Dataverse from workflows in Azure Logic Apps

Applies to: Azure Logic Apps (Consumption + Standard)

To automate tasks that work with your Microsoft Dataverse database, you can use the Microsoft Dataverse connector with workflows in Azure Logic Apps.

For example, you can build workflows that create rows, update rows, and perform other operations. You can also get information from your Dataverse database and make the output available for other actions to use in your workflows. For example, when a row is added, updated, or deleted in your Dataverse database, you can send an email by using the Office 365 Outlook connector.

The Dataverse connector was previously known as the Common Data Service 2.0 connector and originally known as the Dynamics 365 connector. You can use the Dataverse connector to access Microsoft Dataverse for Microsoft Dynamics 365 Sales, Microsoft Dynamics 365 Customer Service, Microsoft Dynamics 365 Field Service, Microsoft Dynamics 365 Customer Insights - Journeys, and Microsoft Dynamics 365 Project Service Automation.

This article shows how to add a Dataverse trigger or action to your workflow and how parameter options work.

Connector reference

For technical information based on the connector's Swagger description, such as operations, limits, and other details, see the managed connector reference page.

Prerequisites

• An Azure account and subscription. If you don't have a subscription, sign up for a free Azure account.

• A Dataverse Data Service environment and database, which is where your organization stores, manages, and shares business data in a Dataverse database. For more information, see the following resources:

  • Learn: Create and manage Dataverse environments

  • Power Platform - Environments overview

• Basic knowledge about Azure Logic Apps along with the Consumption or Standard logic app resource and workflow from where you want to access your Dataverse database. To use a Dataverse trigger, you need a blank workflow. To use a Dataverse action, you need a workflow that starts with any trigger appropriate for your scenario.

  For more information, see the following resources:

  • Create an example Consumption logic app workflow

  • Create an example Standard logic app workflow

Add a Dataverse trigger

Based on whether you have a Consumption or Standard logic app workflow, follow the corresponding steps:

Add a Dataverse action

Based on whether you have a Consumption or Standard logic app workflow, follow the corresponding steps:

Test your workflow

To run your workflow, follow these steps:

1. On the designer toolbar, select Run > Run.

2. Reproduce the conditions that the trigger requires for your workflow to run.

Return rows based on a filter

For actions that return rows, such as the List rows action, you can use an ODATA query that returns rows based on the specified filter. For example, you can set up the action to return only rows for active accounts.

1. On the designer, in the action, open the Advanced parameters list, and select the Filter rows parameter.

   

2. In the Filter rows parameter that now appears in the action, enter an ODATA query expression, for example:

   statuscode eq 1

   

For more information, see the following documentation:

• List rows
• $filter system query options

Return rows based on a sort order

For actions that return rows, such as the List rows action, you can use an ODATA query that returns rows in a specific sequence, which varies based on the rows that the action returns. For example, you can set up the action to return rows organized by the account name.

1. On the designer, in the action, open the Advanced parameters list, and select the Sort By parameter.

   

2. In the Sort By parameter that now appears in the action, enter the column name to use for sorting, for example, name:

   

For more information, see the following documentation:

• List rows
• $orderby system query options

Field data types

In a trigger or action, a field value's data type must match the field's required data type. This requirement applies whether you manually enter the value or select the value from the dynamic content list.

For example, suppose that you have a table named Tasks. This table has fields that apply only to that table, while other tables have their own fields. For the example Tasks table, the following table describes some sample field types and the data types that those fields require for their values.

For the example Tasks table, suppose you use the Add a new row action to create a new row that's associated with other entity rows, specifically a user row and an account row. So, in this action, you must specify the IDs and lookup types for those entity rows by using values that match the expected data types for the relevant properties.

• Based on the Owner property, which specifies a user ID, and the Owner Type property, which specifies the systemusers lookup type, the action associates the new row with a specific user.

• Based on the Regarding property, which specifies a row ID, and the Regarding Type property, which specifies the accounts lookup type, the action associates the new row with a specific account.

The resulting action looks like the following example:

Troubleshooting problems

Calls from multiple environments

The Dataverse connector stores information about the logic app workflows that get and require notifications about database entity changes by using the callbackregistrations entity in your Dataverse database. If you copy a Dataverse organization, any webhooks are copied too. If you copy your organization before you disable workflows that are mapped to your organization, any copied webhooks also point at the same logic app workflows, which then get notifications from multiple organizations.

To stop unwanted notifications, delete the callbackregistrations entity from the organization that sends those notifications by following these steps:

1. Identify and sign in to the Dataverse organization from where you want to remove notifications.

2. In the Chrome browser, find the callback registration that you want to delete.

   1. Review the generic list for all the callback registrations at the following OData URI so that you can view the data inside the callbackregistrations entity:

      https://{organization-name}.crm{instance-number}.dynamics.com/api/data/v9.0/callbackregistrations:

      Note

      If no values are returned, you might not have permissions to view this entity type, or you might not have signed in to the correct organization.

   2. Filter on the triggering entity's logical name entityname and the notification event that matches your logic app workflow (message). Each event type is mapped to the message integer as follows:

      Event type	Message integer
      Create	1
      Delete	2
      Update	3
      CreateOrUpdate	4
      CreateOrDelete	5
      UpdateOrDelete	6
      CreateOrUpdateOrDelete	7

      The following example shows how you can filter for Create notifications on an entity named nov_validation by using the following OData URI for a sample organization:

      https://fabrikam-preprod.crm1.dynamics.com/api/data/v9.0/callbackregistrations?$filter=entityname eq 'nov_validation' and message eq 1

      

      Note

      If multiple triggers exist for the same entity or event, you can filter the list by using additional filters such as the createdon and _owninguser_value attributes. The owner user's name appears under /api/data/v9.0/systemusers({id}).

   3. After you find the ID for the callback registration that you want to delete, follow these steps:

      1. In your Chrome browser, open the Chrome Developer Tools (Keyboard: F12).

      2. In the window, at the top, select the Console tab.

      3. On the command-line prompt, enter this command, which sends a request to delete the specified callback registration:

         fetch('http://{organization-name}.crm{instance-number}.dynamics.com/api/data/v9.0/callbackregistrations({ID-to-delete})', { method: 'DELETE'})

         Important

         Make sure that you make the request from a non-Unified Client Interface (UCI) page, for example, from the OData or API response page itself. Otherwise, logic in the app.js file might interfere with this operation.

   4. To confirm that the callback registration no longer exists, check the callback registrations list.

Duplicate 'callbackregistrations' entity

In Standard workflows, under specific conditions such as instance reallocation or application restart, the Microsoft Dataverse trigger starts a duplicate run, which creates a duplicate callbackregistrations entity in your Dataverse database. If you edit a Standard workflow that starts with a Dataverse trigger, check whether this callbackregistrations entity is duplicated. If the duplicate exists, manually delete the duplicate callbackregistrations entity.

Related content

• Managed connectors for Azure Logic Apps
• Built-in connectors for Azure Logic Apps
• What are connectors in Azure Logic Apps