Automated triggers and conditions

1. Automated triggers and conditions

Welcome back. Last video wired up a Recurrence trigger. Now we flip to the other pattern — a flow that fires when something changes in your data store, and a cost trap that catches people out.

2. An event listener, not a clock

A scheduled flow asks what's changed since last time? every time it wakes up. An automated trigger asks nothing. It sits quietly until the platform notices a change and pushes it to your flow. One fire per event. No polling, no wasted runs on quiet days, and no missed events between ticks.

3. Configuring the change event

Power Automate works against two main Microsoft data stores. Dataverse holds typed-column tables and exposes a row-change trigger, When a row is added, modified or deleted. Pick a Change type, a Table name, and a Scope (for production, Organization). SharePoint's equivalent is When an item is created or modified, where you pick a Site Address and a List Name. Same shape, different labels. Hands-on work in this course uses SharePoint; the patterns map to Dataverse directly.

4. Filter rows: server-side and free

Here's Dataverse's signature advantage. The Filter rows field accepts an OData expression that gets evaluated server-side, before the trigger hands off. Notify when a contract is renewed set up correctly fires only when status changes to Renewed, not on every row edit. Get the filter right and you've already handled what would otherwise need a Condition action inside the flow. And rejected events cost nothing. SharePoint's item trigger has no equivalent, so you reach for trigger conditions instead.

5. Same idea, every trigger

That's everything on Dataverse for now, so let's zoom out to the general case. Filter rows is Dataverse-specific. The general-case version, available on every trigger including Recurrence, is the trigger condition. Open the trigger's three-dot menu, choose Settings, scroll to Trigger Conditions. Each entry is a boolean OData expression with the same operators you already know: equals, greater, and, or. Typical uses: fire only on weekdays, fire only when priority is High, fire only when a subject contains a keyword. Anything that says don't bother with this run.

6. The cost trap on Recurrence

Here's a trap worth knowing. Suppose a Recurrence flow has a trigger condition that filters out 95% of runs. You might expect those rejected runs to be free, but they aren't. The trigger fires, the condition checks, the run gets cancelled, and the platform still counts it against your quota. On a Developer Plan that's 750 runs a month, and cancelled runs eat into that ceiling fast. Contrast that with Dataverse Filter rows, which evaluates server-side. If it rejects 95% of events, only 5% ever reach Power Automate. The other 95% cost nothing. In the editor they look identical, but the billing difference is huge. Use Filter rows wherever you can.

7. Debugging a flow that won't fire

When a flow stops firing, run history is normally your first stop. Look at this example: both runs succeeded, so everything looks fine. But trigger conditions have a twist. Rejected runs never appear in run history at all. Power Automate silently skips them. So the diagnostic clue isn't a failed-status label, it's the gap between runs you expected and runs you actually see. If your flow should have run five times this week but you only count two, three were silently rejected. Check your condition expression against the actual field values in your data store to find the mismatch.

8. Let's practice!

Now let's wire a SharePoint trigger and set up conditions.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.