PowerBI Autotask OData Connector Times Out After 6 Minutes On Refresh

I have a PowerBI Gen 1 Dataflow (on a workspace with a PPU license) that is accessing our Autotask OData connection. It times out after 6 minutes and a few seconds no matter what I do. I have smaller dataflows that work fine.

The source in PowerBI is:

OData.Feed("https://bridge-online.invantive.com/XXXXXXX-XXXXXXXX/odata4", null, \[Implementation="2.0", ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=\[Referer="Autotask Ticket Fact Dataflow"\], Timeout=#duration(0,4,0,0)\])

I have replaced the 4 hour timeout duration with 30 minutes; still times out after 6 minutes.

Query folding is in place and working, the query is (from Bridge Online Monitoring):

SQL-statement

select t.[id], t.[assignedResourceID], t.[companyID], t.[completedByResourceID], t.[completedDate], t.[contactID], t.[createDate], t.[firstResponseDateTime], t.[issueType], t.[lastActivityDate], t.[lastActivityResourceID], t.[priority], t.[queueID]...ubIssueType], t.[ticketCategory], t.[ticketNumber], t.[title]
from   Autotask.Tickets.Tickets@at t
where  ((queueID in (:w1, :w2, :w3, :w4, :w5, :w6, :w7, :w8, :w9, :w10, :w11, :w12) and ([lastActivityDate] >= :w13)) and ([lastActivityDate] < :w14))

Parameter Values

w1 = 8 (int32)
w2 = 29,682,833 (int32)
w3 = 29,682,969 (int32)
w4 = 29,683,354 (int32)
w5 = 29,683,486 (int32)
w6 = 29,683,488 (int32)
w7 = 29,683,489 (int32)
w8 = 29,683,490 (int32)
w9 = 29,683,493 (int32)
w10 = 29,683,496 (int32)
w11 = 29,683,497 (int32)
w12 = 29,683,501 (int32)
w13 = 20-10-2021 00:00:00 (datetime)
w14 = 20-10-2025 00:00:00 (datetime)

The error from Bridge Online Monitoring is:

Request ID: 0HNGFO77CP4CC:00000005 (HTTP/2)

itgenboe161
The data download was cancelled after 6 minutes, 6 seconds, such as by the user navigating away in the Power BI or Power Query user interface.
Please optimize your query as described on Overview of Power BI Performance and Download Size Improvement Techniques - invantive .
Then re-run the query. (/XXXXXXX-XXXXXXXX/odata4/Autotask.Tickets.Tickets@at?$filter=%28queueID%20eq%2…teTime%2Csource%2Cstatus%2CsubIssueType%2CticketCategory%2CticketNumber%2Ctitle).

This is the result of a dataflow refresh, so no navigating away going on.

Can you try to execute the URL from a browser or curl as described in How do I use curl to execute an Invantive Cloud OData4 request? ?

This helps to differentiate whether it is a problem with the Power BI Service or Invantive Cloud. First hunch is that Power BI Service backs off too early. A dataflow can also cancel the download clientside, not only interactive users.

An alternative would be to optimize the query or chop the date range in pieces, such as by year. It depends on the number of tickets in this time range for these queues. When it is are just thousands, it should work. When it are hundreds of thousands, splitting might help.

According to system logs, the download has been returning rows at a steady state, delivering 31.913 rows just before the client was detected to have disappeared.

Thank you for the quick response. Curl responded as follows and returned 31,907 rows in 6m19s, comparing to Autotask I do believe this to be all the rows for this query:

It did come up with an error message at the end (yellow). When comparing to the refresh from the dataflow, the dataflow returned 31,913 rows when it errored, suggesting it returned it all, here is how monitoring online looks from the dataflow refresh:

So bizarrely it looks like the dataflow refresh works but the $select error triggers the failure message in monitoring online

The $select error is probably due to incorrect escaping on the command line and can probably be ignored.

It is recommended to try again tomorrow. There have been no changes on Bridge Online and App Online since end of July 2025, but Azure can fluctuate sometimes.

Thanks, this is a consistent issue, has been happening consistently for a month or so and same again today:

I ran a larger dataset and refreshed from PowerBI … ran for 14 minutes to completion and still the same monitoring online warning:

As it appears to be returning all records despite the monitoring error, I’m not overly concerned.