Most people build their first flow around "When a new email arrives" and treat it like a doorbell. Something happens out there, the doorbell rings in here, the flow reacts. That model holds up right until a flow starts a full minute after the email actually landed, or fires twice for a single change, and the doorbell stops making sense.
That confusion isn't a sign you're missing something obvious. Power Automate hides two genuinely different mechanisms behind the same friendly trigger name, and gives you almost no visual cue for which one you're looking at. A trigger says "when X happens", and nothing tells you whether X is something the flow is watching for, or something the flow is repeatedly going out and checking on.
The mental model
A trigger isn't an event. It's a question, and there are two kinds.
A polling trigger asks the same question on a loop: "has anything changed since I last checked?" It stores a marker (a timestamp, an ID, whatever the connector uses to remember where it left off), wakes up on a schedule, asks again, and only runs your flow if the answer changed. Nobody told it anything happened. It went looking.
A push trigger doesn't ask anything. It registers itself with the service and waits to be told. The service holds the address of your flow, and when the thing happens, the service calls that address directly. No schedule, no repeated checking. The flow runs because it was notified, not because it happened to check at the right moment.
This is the actual reason "instant" triggers feel instant and some "automatic" ones don't. It has nothing to do with how important Microsoft considers your connector.
The two mechanisms, not the two names
Take SharePoint's "When an item is created". It's a polling trigger. By default it checks the list once a minute, and that interval is configurable: open the trigger's settings, look under trigger conditions, and adjust the interval and frequency yourself. Every run of that flow, whether or not an item exists to process, is Power Automate asking the same question again on your schedule.
Now take "When an HTTP request is received". It's a push trigger. Power Automate generates a callback URL, hands it to whatever's calling it, and does nothing until that URL is hit. No polling loop, because there's nothing to check on a timer. The flow is asleep until the call arrives.
The connector's icon and the trigger's plain-English name give you no reliable signal here. Some services expose the same real-world event both ways, a polling version on the standard connector and a push version on a premium or preview one, and the only way to tell which you've picked is whether the trigger has an interval and frequency setting at all. If it does, you're polling. If the only settings are a callback URL or a subscription, you're being told.
Why your approval flow "takes forever" to start
This is the version that actually shows up in inboxes. Someone submits a form, a SharePoint item gets created, and the approval flow that's supposed to email the manager doesn't start immediately. A minute passes, sometimes more, and the person who submitted the form assumes Power Automate is slow, or broken, or that IT should look into it.
It isn't slow. It's polling, on the default interval, exactly as configured. The flow hasn't been told anything happened, because that connector doesn't work that way, and it won't run again until its next scheduled check comes around. The fix isn't a support ticket. It's opening the trigger's settings and tightening the interval and frequency, understanding that a tighter interval means more checks against that connection, or accepting the lag as a reasonable cost of a connector that happens to poll.
Knowing this before someone complains is the entire value of the mental model. You're not debugging a mystery. You're reading a setting.
What it doesn't do
A polling trigger doesn't guarantee one run per change. If three items change between one poll and the next, most polling triggers pick up all three on the next check, sometimes in one run, sometimes as separate runs queued back to back. If your flow logic assumes one trigger fire per item, a batch of near-simultaneous changes will expose that fast.
A push trigger doesn't guarantee it stays registered forever. Some webhook-based triggers hold a subscription with the service that can expire or need renewal, quietly, in the background. When that lapses, the flow doesn't error, it just goes silent, because nothing is calling it and nothing is checking either. That silence is harder to spot than a slow polling flow, because there's no lag to notice, just an absence.
Neither category is the "better" one. A push trigger that's stopped listening is invisible until someone notices nothing happened. A polling trigger checking too often is a real, measurable cost against your connection's request limits. Which you'd choose, if a connector genuinely offered both, depends on whether you'd rather debug a delay or debug a silence.
Frequently Asked Questions
Does every Power Automate trigger fall cleanly into poll or push?
Almost all of them do, but the split isn't obvious from the trigger's name. The reliable tell is whether the trigger's settings expose an interval and frequency. If they do, it's polling. If the only configuration is a callback URL or a subscription, it's push.
How do I check which type a specific trigger is using?
Add the trigger to a flow, click the ellipsis in the top right of the trigger card, and open Settings. A "Trigger Conditions" section with interval and frequency fields means polling. No such section, usually paired with a generated URL, means push.
Can I make a slow polling trigger check more often?
Yes, within limits. The interval and frequency fields in trigger settings control exactly this. Checking more often means more API calls against that connection, so tightening the interval is a trade-off, not a free win.
Does polling cost me anything I should care about?
It counts against the connector's API request limits even on runs where nothing changed, because the check itself is a request. A trigger polling every minute makes 1,440 checks a day whether or not anything ever happens. Worth knowing before you set the interval as tight as it'll go out of habit.
What about manual and scheduled triggers, are those push or poll?
Neither. A manually triggered flow runs because someone clicked a button, and a recurrence trigger runs on a fixed schedule you set yourself, not because it's watching or asking about anything external. A third category worth knowing exists, but it doesn't carry the poll-versus-push distinction because there's no external event being detected.
Do premium connectors always use push triggers?
No. Plenty of premium connectors poll, and plenty of standard connectors offer genuine push triggers. Premium licensing is about the connector tier, not the trigger mechanism, and conflating the two will lead you to guess wrong about how a flow actually behaves.
Once you can see a trigger as one of these two questions instead of a doorbell, the rest of the Power Automate series this month gets easier to read. The Hot Take landing on the 5th is about what happens when nobody's accounted for a flow quietly asking one of these questions on your behalf, and Between the Sheets starts its own trigger-and-connector deep dive on the 6th, building straight on the distinction made here.