Which Dataverse Trigger Fires on a Custom API Action?
A company implements a Microsoft Dataverse custom API named SubmitForReview. This action: • Runs complex business logic to create a record. • Is used by multiple apps and services. The company requires a Power Automate cloud flow that: • Runs every time the SubmitForReview action is run. • Avoids triggering on unrelated record updates. You need to recommend a trigger change type. Which trigger change type should you recommend?
Community Insight
The test is whether you can distinguish an action-based Dataverse trigger from row-based triggers, and the common trap is picking any 'row added/modified' trigger, which fires on unrelated record updates.
This Power Platform question asks which Dataverse cloud-flow trigger responds to a custom API action named SubmitForReview rather than to ordinary row changes. The page establishes that 'When an action is performed' is the trigger designed specifically to run when a Dataverse action, including a custom API action, is invoked.
The most common wrong answer is B, 'When a row is added, modified, or deleted,' because creating a record in the custom API logic makes it tempting; but that trigger fires on all row changes and would also run on unrelated updates, violating the isolation requirement.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option A, "When an action is performed," is the Dataverse trigger purpose-built to fire when a specific action — including a custom API action such as SubmitForReview — is invoked. Because the requirement is that the flow runs every time the SubmitForReview action is run, an action-scoped trigger matches that contract exactly and scopes the trigger to the named action rather than to general data mutations. Custom API actions are exposed in Dataverse as actions, so the action trigger can be filtered to that action and will not react to ordinary row writes.
Why the Other Options Are Wrong
Option B, "When a row is added, modified, or deleted," is row-scoped: it fires on any insert, update, or delete across the table, so it would trigger on unrelated record updates and directly violates the requirement to avoid them. Option C, "When a row is selected," is a selection-oriented trigger tied to user interaction with a row, not to execution of a server-side action, so it would never fire when apps or services call the custom API. Option D, "When a row is added," only reacts to record creation and would still trigger on unrelated inserts while missing the action invocation itself, since the action's internal record creation is an implementation detail rather than the contract the flow must observe.
Community Comment Notes
A single learner comment supported the same conclusion, selecting answer A with "When an action is performed" as the reasoning. No dissenting comments were posted, so the community view aligns with the technical design of Dataverse action triggers, though the vote count is too small to serve as independent evidence on its own.
Official Reference
Exam Strategy
Read the trigger name literally: if the requirement says the flow must run when an action is invoked, choose the action-scoped Dataverse trigger and reject any option worded around rows, records, or selections. Ask yourself whether the trigger would also fire on unrelated data changes — if yes, it fails the isolation requirement.
Frequently Asked Questions
Why does 'When a row is added, modified, or deleted' fail this requirement?
It is row-scoped, so it fires on every insert, update, or delete across the table, including unrelated record changes, which the company explicitly wants to avoid.
Can a Dataverse action trigger target a specific custom API action?
Yes. The 'When an action is performed' trigger can be filtered to the named action, so only SubmitForReview invocations start the flow.