Implementing triggers for Power Automate flows that are not supported by the Dataverse connector

The Dataverse connector allows us to trigger Power Automate Cloud flows based on events that occur on Dataverse. These events include the creation, deletion and modification of a record or the execution of an action or from a step in a business process flow. Generally speaking, these triggers serve a large variety of requirements and give the flexibility to implement efficient triggers. However, does the connector support all Dataverse tables? If not, how can we trigger a Flow after an event on a table not supported by the connector?

Dataverse Connector limitation

Recently, a member of the forum asked if it is possible to trigger a Flow when an activity is updated. The discussion concluded that the Dataverse connector does not support the Activity table, which is indeed a very special table on Dataverse.

By reproducing the same scenario, the trigger returns the following error at the trigger level: Creating a callback registration on entity type activitypointer is disallowed.

As the activity table represents a set of tables that are of type activity. It was proposed to register separate flows for each of the activity entities. This approach will work without any problem, but it will generate a lot of flows that are similar to each other. In this way, it is necessary to maintain the flows when the collection of tables of activity types changes.

Power of custom connectors

After some investigation, I was able to create a custom trigger that will run Cloud flows on the change of an Activity record. Before going into the details of the Custom Connector, let’s see why the Dataverse connector does not support the Activity table.

The Dataverse connector is a WebHook type that needs to be notified when a message is executed, and according to the Microsoft documentation, the Activity table supports only the following three operations: Retrieve, RetrieveMultiple and Rollup. Consequently, the Dataverse connector will never be able to execute for messages that are not supported by the activity table.

Thankfully, custom triggers are not limited to the WebHook type. There is a second type which is called “Polling Trigger”.

A polling trigger is an implementation that regularly calls your REST API service and checks for new data. After the platform has determined that new data is available, the trigger fires and passes the new collected data to a cloud flow or a Logic Apps workflow.

This type of trigger only requires the RetrieveMultiple message which is supported by the Activity Table. We will use this capability to build the custom connector.

Custom Trigger – When an activity is updated

Our polling trigger will start by retrieving data from the Activity table and defining a state. Then it will periodically check for updates by requesting all the data since the last update of the state, for this we will use the createdOn and modifiedOn fields. Once the new data has been retrieved, the new state is defined and the process continues. If the trigger retrieves a new data, the flow will be executed. Otherwise, the trigger will wait for the next period to check if there is a new data to process.

Trigger Definition

When creating a trigger, we have the possibility to choose between two types: WebHook and Polling. In our case, we will choose the Polling type:

Then we have to teach the trigger how to look for the new data. This part is configurable in the requests section.

When an activity is modified is equivalent to searching all activities with the creation date is different from the modification date.

The new data corresponds to the data that is modified after the last data set retrieved. This part is tricky. Indeed, we will need to sort the activities according to the modification date. Thus, we can use the most recent modification date to generate our query.

So our query requires two parameters: filter and orderby

Our filter will be defined as an internal parameter. The expression will be configured in the trigger configuration.

The orderBy parameter which will represent the order of the records will be static. Its expression corresponds to : “modifiedon desc”

Now we will configure the trigger. That is, the filter that will allow you to retrieve the new data. The expression used is: (modifiedon ne createdon and modifiedon gt @{triggerBody().value[0].modifiedon})

Then the collection of the data is defined by @triggerBody().value


The demonstration below illustrates the use of the custom trigger. I mark 4 activities of different types as completed. Then I wait for the flow to be triggered and I check that the flow has retrieved the 4 activities to process them.

One thought on “Implementing triggers for Power Automate flows that are not supported by the Dataverse connector

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s