When a Cloud Flow Stops Triggering… Even Though Nothing Is Wrong

Alex Weaver

— 3 min read

So here’s a fun one I ran into recently.

I had a Power Automate cloud flow — simple Dataverse trigger, nothing fancy — that did work at one point.
After making some changes, it suddenly stopped firing.

No errors.
No warnings.
Just… nothing.

Naturally, I tried all the usual things:

  • deleting and recreating the trigger
  • resetting connection references
  • recreating actions
  • turning the flow off and on again (obviously)

None of it worked.

The only reliable way I found to fix it was to duplicate the entire cloud flow.
The new one would run perfectly — even though it was a carbon copy of the original.

🔎 The Culprit

After a lot of digging, I discovered there’s a hidden table that holds Dataverse trigger information called:

Callback Registrations

This table holds the actual trigger configuration used by the platform — not just what you see in the flow designer.

Apparently this table has a bit of a reputation. Over the years people have reported:

  • trigger entries disappearing entirely
  • broken references to cloud flow IDs
  • filters behaving very differently to what the UI shows

So I had a look.

🧪 Checks

First, you’ll need the workflow ID for the cloud flow in question.
You can retrieve it with the following query — just replace the environment and the flow name (inside the quotes):

Get Cloud Flow ID 
https://<environment>.crm.dynamics.com/api/data/v9.2/workflows?$select=workflowid,name,category,statecode&$filter=category eq 5 and statecode eq 1 and name eq "<your flow name>"

Next, query the callback registration table:

Get Callback registration entries 
https://<environment>.crm.dynamics.com/api/data/v9.2/callbackregistrations

You should find an entry where the name or workflowid matches your cloud flow.

An example record looks like this:

      {
         "@odata.etag":"W/\"4343159\"",
         "_createdonbehalfby_value":null,
         "runas":1,
         "url":null,
         "_owninguser_value":"c0685462-bd5c-f011-bec1-6045bd1197e4",
         "scope":4,
         "harddelete":false,
         "filteringattributes":"dateofbirth",
         "name":"34686658-eea8-f011-bbd3-6045bdc1830d:MTA",
         "_createdby_value":"c0685462-bd5c-f011-bec1-6045bd1197e4",
         "_modifiedonbehalfby_value":null,
         "_owningbusinessunit_value":"eb162be3-4c58-f011-bec2-6045bdd11f49",
         "versionnumber":4343159,
         "version":1,
         "postponeuntil":null,
         "_owningteam_value":null,
         "entityname":"customers",
         "logicappsversion":"08584410933555654208",
         "_modifiedby_value":"c0685462-bd5c-f011-bec1-6045bd1197e4",
         "callbackregistrationid":"080cfa0c-99a9-f011-bbd3-7ced8d9a42f7",
         "sdkmessagename":null,
         "modifiedon":"2025-10-15T07:32:10Z",
         "runtimeintegrationproperties":null,
         "message":4,
         "_ownerid_value":"c0685462-bd5c-f011-bec1-6045bd1197e4",
         "softdeletestatus":0,
         "filterexpression":active eq 1,
         "createdon":"2025-10-15T07:32:10Z"
      }

❗ The Problem

When I checked my cloud flow trigger in the designer, the filter was blank.

But in the callback registration table, filterexpression still contained a value we had used earlier — one that had supposedly been removed.

That stale filter was the reason the cloud flow wasn’t triggering.

This also explains why duplicating the cloud flow “fixed” it:
a brand-new callback registration record was created, this time with the correct (empty) filter expression.

And that wasn’t the end of it…

A few weeks later we hit the same issue again, this time with the filteringattributes column behaving in exactly the same way.

Why?

It turns out that blanking a field in the trigger does not (currently) remove it from the callback registration table.

So what you end up with is:

  • the front end saying “no filter”
  • the back end still enforcing one
  • a cloud flow that never fires
  • and a developer questioning their life choices

In other words: the UI and backend quietly diverge — and nobody tells you.

🛠️ The Solution

At the moment, the only reliable fix (other than duplicating the flow) is to force Dataverse to overwrite the old value.

To do that, add a filter expression that always resolves to true.
In our case, we used:

active eq 1

Save the flow.

Once Dataverse updates the callback registration entry, the trigger starts behaving again.

Other Issues

While hunting this down, I also came across reports of:

  • completely missing callback registration entries
  • broken registrations when the owning user account is disabled or removed
  • triggers that silently stop working after environment changes

None of which are particularly fun to debug.

🧠 Final Thoughts

This is one of those Power Platform issues where everything looks correct — until you realise the real configuration lives somewhere else entirely.

If you ever have a Dataverse-triggered flow that suddenly stops firing for no obvious reason, it’s worth checking the callback registration table before you lose too much time.

And with a bit of luck…
this should still work 😉

📚 References & Notes

🧪 Tested on: Power Platform / Dataverse — Late 2025
🔍 Table involved: callbackregistrations

Read more