Why do your data events never fire for some entities?

Because of one sentence in Microsoft's limitations list, and the scope in it is the whole answer:

"Data events in Microsoft finance and operations apps are designed to trigger on create, update, and delete (CUD) operations for entities that tables back. When a data entity uses a view as its primary data source, data events don't trigger." — Data events

Read the qualifier, not the headline. Microsoft's condition is that the entity uses a view as its primary data source — not that a view appears somewhere in the entity, not that the entity is complex, not that data events are unreliable in general. Microsoft's verb is "don't trigger"; "never fire" is ordinary English for the same categorical statement. The scope is the part you have to keep.

So the honest form of the title is: data events don't trigger for entities whose primary data source is a view. Everything below either supports that sentence or names a different failure that looks like it.

What data events are, and what they need

Data events [GA] are the change-feed cousin of business events: "events that are based on changes to data in finance and operations apps. You can enable create, update, and delete (CUD) events for each entity."

That label rests on the absence of a preview designation on the data events page, not on a Microsoft status statement — no page opened for this article uses the phrase "generally available" about data events specifically. That is a weaker basis than a dated status sentence would be, and it is stated so you can check it rather than take it.

They carry a prerequisite, stated in an Important callout: "Data events are available only in environments that have the Microsoft Power Platform integration enabled." That is a platform decision, usually made long before your integration exists, and if it has not been made the entity question never arises.

Microsoft's reasons, which predict the next entity

Microsoft does not just state the limitation — it gives the mechanism, and the mechanism is more useful than the rule because it tells you what else will behave this way:

"Views aren't directly tied to a single table's data change." · "The system can't determine which underlying table change should trigger the event." · "As a result, the event framework can't reliably emit notifications for entities based on views."

The framework needs to attribute a change to one table. A view over several tables gives it no such attribution, so it emits nothing rather than guessing. The reason Microsoft gives is structural — a property of how the entity is defined — which is why activating the event, re-activating it or changing the endpoint does not address it.

The tension on the same page, worth knowing before you plan

The page's overview says "All standard and custom entities in finance and operations apps that are enabled for Open Data Protocol (OData) can emit data events." The limitations list then carves the view-primary-source case out of that.

Our reading, not a Microsoft statement: the overview describes the catalog — which entities appear and can be activated — and the limitation describes runtime. An entity can be OData-enabled, appear in the catalog, accept an activation, and still emit nothing. Plan from the overview sentence alone and you build a subscription list that half works.

A different failure that looks like the same one

There is a second entity class where data events do not arrive, and it is worth separating because the symptom is the opposite. From the troubleshooting page:

"Virtual tables, and the associated data events, don't support entities that have temporary tables as backing tables for the entity."

Microsoft's worked case is data events on EcoResProductV2Entity with the Engineering Change Management configuration key disabled, which errors on creating a released product: "Cannot execute a data definition language command on Products V2 (EcoResProductV2Entity)."

The stated cause is that disabling a configuration key swaps that key's physical tables for temporary ones, so "a temporary table [is] included in the virtual table query, which causes the error message." Microsoft's remedies: enable the configuration key, or use another entity such as RetailEcoResProductEntity.

View-primary-source entities are quiet. Temporary-table-backed entities are loud. The data events page documents no error, no log entry and no indication for the view case — it simply does not trigger. The temporary-table case stops a business transaction and names the entity in the message. Diagnosing them the same way wastes a day.

Two more ways an event does not arrive

Change tracking is a precondition, and Microsoft hedges the consequence — Microsoft's Tip: "Change tracking is essential for enabling incremental data export and for triggering data events in finance and operations apps. Without change tracking enabled on a data entity, only full data exports are possible, and data events might not fire as expected."

Keep the hedge. Microsoft says might not fire as expected, which is weaker than the view limitation's don't trigger, and we should not sharpen someone else's caution into a rule.

Virtual fields do not trigger a data event, by construction — "Modify data events are triggered by update operations on the underlying tables of an entity. Because virtual fields are values calculated in X++ code, any change in the value doesn't result in any data operations against the physical tables and doesn't trigger a data event." A computed field changing is not a write, so there is nothing for the framework to notice.

The throughput envelope, in Microsoft's words including the hedge

"The data events functionality currently supports a burst rate of 5,000 events per five-minute period, up to 50,000 events per hour, across all entities for the environment. Event loads above these thresholds might encounter performance degradation in environment processing. The environment doesn't have limits that explicitly throttle events. The environment still sends any events above the supported thresholds, but it might slow the performance of the environment."

Three things to take from that paragraph and nothing more.

The figures are per environment — Microsoft's phrase is "across all entities for the environment". A subscription list assembled by several teams shares one budget.

There is no explicit throttle — Microsoft's sentence is about limits, not about a response code. It names no status code on this page, so we do not name one either. What the page says happens above the threshold is that the environment "still sends" and "might slow" — degradation rather than rejection.

Update events cost more than create and delete — "Data events for update operations are inherently more expensive to process than data events for create and delete operations… you might see environment performance degrade more quickly when exceeding the supported thresholds."

The design consequence is worth saying plainly: a pattern that degrades instead of rejecting gives you no signal at the moment you cross the line. The ERP gets slower, and the slowness gets attributed to whatever else changed that week.

Bulk imports, where Microsoft documents switching the pattern off

This is the part most integration designs skip, and it is documented:

"Like business events, you can deactivate data events when business event processing is temporarily paused. A temporary pause might be required because of system maintenance, bulk data imports, or bulk data processing. Bulk data processing where data events are enabled on related data entities can send a high volume of data events that might not be required. This situation can affect system performance."

Microsoft's documented option for a bulk import is that you can deactivate the data events while processing is paused. That is sound, and it has a consequence the page does not follow up on: your near-real-time change feed has a documented off switch, operated by hand, on the day of the highest change volume of the month.

Whatever consumes those events has to catch up afterwards from the records rather than from the events that were never sent — which is where this lands in the same place as the business events ordering limitation, reached from a different direction.

What we build against this

Ours, not Microsoft's. Three positions, each following from a quotation above.

Entity-by-entity feasibility before subscription design — The view-primary-source rule is a property of the entity definition, so it is answerable at design time, and far cheaper there than after a pilot.

A reconciliation read that does not assume the event arrived — Deactivation during bulk imports, change tracking's hedge and the degradation envelope produce the same gap: work happened that no event described. A periodic read of the ERP closes it. Counting events does not.

Update-event budgets set deliberately — Microsoft says update events cost more, so a list that watches updates on high-churn entities spends the shared budget fastest. We name what each subscription is for and drop the ones that exist because the checkbox was there.

Activating a data event is a catalog operation on Microsoft's own page — select it, select Activate, choose an endpoint — not a change to the ERP core. Dynamics stays the system of record; the Optimizer subscribes where subscribing works, reads where it does not, and writes its decision back through a governed surface.

What to check this week

For each entity you subscribe to, check whether its primary data source is a view. That one property decides whether the subscription can deliver at all.
Confirm change tracking is enabled on every entity in your data event list. It is Microsoft's own precondition, and its absence is the quiet case.
Review your active data event count and its create/update/delete mix beside your integration volumes. The thresholds are per environment, shared by every team that added a subscription.
Write the post-bulk-import catch-up before the first import that needs it. The deactivation step is documented; the recovery step is yours.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Which entities can carry an event, and which have to be read, is a decision made once and lived with for years. Book a fifteen-minute call and we will walk your entity list and your change feed with you on your own environment — no deck. https://cognilium.ai

Why do your data events never fire for some entities?