SharePoint Alerts Are Weak: Replace SharePoint Alerts With Power Automate
Classic SharePoint alerts fire on everything and get ignored. Here is how to replace SharePoint alerts with Power Automate and send notifications people actually read. No code.
In this article · 7 sections
Your classic SharePoint alert is a smoke detector that beeps every time you make toast. It fires on every change, formats every message the same way, sends it to whoever clicked “Alert Me,” and then everyone builds an Outlook rule to bury it in a folder they never open.
You may have heard that alerts are going away. Before you panic about a deadline, do one honest thing: open the Microsoft 365 Message Center in your tenant and search “alerts.” That is where any real timeline for your organization would show up, and Microsoft has a habit of moving these dates, so trust your Message Center and the Microsoft 365 Roadmap over any blog, including this one.
Here is the part that matters more than any date. Classic alerts are a legacy feature, and they were never good. Whether or not a retirement notice lands in your tenant this year, this is the moment to stop treating notifications as a checkbox and start building ones with a brain. When you replace SharePoint alerts with Power Automate, you are not migrating a feature. You are retiring a limitation.
Why classic alerts are a dead end
Think about what a classic alert can actually do. It can tell you an item was added, changed, or deleted. That is the whole menu. It cannot ask “was this the item I care about?” It cannot send different messages to different people. It cannot format a single word.
Microsoft has spent years steering SharePoint automation toward Power Automate and away from older engines like the 2010 and 2013 workflows, which are formally retired. The direction is not subtle: new investment goes into Power Automate, and alerts sit still. That is reason enough to move, no shutdown date required.
So treat the alerts conversation as permission. You now have a reason to fix notifications you would never have prioritized on your own.
Takeaway: Stop asking “when do I have to move?” Start asking “what should this alert have been doing all along?”
Why your manager will care (before we touch a single setting)
Nobody gets promoted for building alerts. People get promoted for making sure the right thing happens at the right time.
An alert that fires on every edit gets filtered into a folder and ignored. When that happens, the overdue invoice sits. The approval waits three days. The contract renewal slips past its date. Those misses cost real money and real trust, and the person who set up the alert usually gets blamed for the silence.
Power Automate for SharePoint changes the math. Notifications can carry logic, so a person only gets pinged when something genuinely needs them. Fewer noise emails. Faster response on the items that matter. And here is the quiet win your manager will love most: the process survives when the person who built it leaves, because it lives in a flow, not in one employee’s personal alert subscription.
Takeaway: The goal is not “new tool.” The goal is that people stop ignoring your notifications.
The 15-minute like-for-like replacement
Start by proving continuity. Rebuild one alert so your team stops worrying, then improve it later. This should take about 15 minutes (illustrative; calibrate against your own list and comfort level).
A flow is like an email rule, but for your whole business process. It has two parts you need to know:
- A Trigger is the event that starts the flow.
- An Action is what the flow does in response.
Here is the like-for-like rebuild:
- Go to Power Automate and select Create, then Automated cloud flow.
- Give it a clear name like “Contracts list - notify on new or changed item.”
- For the Trigger, search SharePoint and choose When an item is created or modified. Point it at your site and your list. Microsoft documents this trigger and its settings in the SharePoint connector reference.
- Add a new step and choose the Send an email (V2) action. Fill in the recipient, a subject, and a body.
- Select Save, then Test by editing an item in your list.
That is a working replacement for your old alert. If you have never done this before, walk through your first Power Automate flow once, then come back. The muscle memory transfers.
What to ask IT before you build
You do not need admin rights, but you do need a few things confirmed. Send your IT contact this:
- License: “Can you confirm my Microsoft 365 plan covers standard Power Automate flows?” The SharePoint trigger, a condition, and Send an email run on standard seeded licensing for most plans. Premium connectors may need more. The current rules live in the Power Automate licensing docs.
- Environment access: An Environment is a workspace for your apps and flows. Ask “Which environment should I build this in?” so you are not creating flows in a place IT plans to clean up.
- DLP approval: A DLP Policy is IT’s rulebook for which apps are allowed to connect to each other. If you want Teams cards later, ask them to confirm the SharePoint and Teams connectors are approved together.
How to frame the whole request in one line: “I am moving off classic SharePoint alerts to a standard flow. Can you confirm my license covers this and approve the SharePoint and Teams connectors?”
One honest caveat: the “created or modified” trigger fires on every edit, including your own. Out of the box it feels as chatty as the old alert. We fix that in the next section.
Takeaway: You just rebuilt your SharePoint alert with no code. That is the floor, not the ceiling.
The upgrade classic alerts never allowed
Now make the flow do what alerts never could.
Send only when it matters. Add a Condition action after the trigger, or use a trigger condition, so the email fires only when Status equals “Overdue” or an Amount is greater than 10,000 (those thresholds are illustrative; industry-standard inputs, calibrate against your own data, actuals vary). In plain terms, you are telling the flow “do nothing unless this is genuinely worth a human’s attention.” That single change turns a firehose into a signal.
Route to the right person. If your list has a Person column or an assigned-owner field, point the email at that value. The alert now reaches the actual owner instead of a static distribution list that half the recipients muted years ago. This is real power automate conditional notifications: right trigger, right filter, right person.
Deliver it in Teams. Adaptive cards are interactive message blocks, a formatted card in Teams instead of a plain email, with buttons people can click without opening SharePoint. This is where power automate adaptive cards earn their keep, because someone can approve or update an item from the message itself. Microsoft walks through the setup in create and use adaptive cards.
Two practitioner caveats before you get excited:
- Adaptive cards in Teams depend on the Teams connector being approved in your DLP policy. Confirm that with IT first, using the line from the callout above.
- Lookup and Person columns from the trigger return only a small piece of data, usually an Id and a display value, not the full details of the related record. If you need more, add a Get item action to fetch the full row. Everyone hits this wall once. Now you will not.
Takeaway: One alert that reaches the right person only when it matters beats fifty that everyone mutes.
The automation you were leaving on the table
Here is the reframe that changes how you work. The same list change that used to fire a dead-end email can now start real work.
You already built the trigger. From there, you are just deciding what should happen next:
- Route an approval request to a manager and record their decision back on the item.
- Send a reminder that escalates to the next person up if an item stays overdue for too long.
- Update several fields, or several items, in one multi-step run.
None of this is a separate skill. It is the same trigger you already have, plus one or two more actions. Microsoft documents the built-in approvals in Power Automate so you are not inventing the wiring yourself.
Takeaway: You already built the trigger. Everything else is deciding what should happen next.
The migration playbook so you don’t create a new mess
Do not clone every old alert. Migrate the value and drop the noise.
- Inventory. Be honest: there is no clean self-service export of every alert across a site. Document the alerts you and your team rely on by hand, or ask IT whether they can pull a report. List the item, the person, and what decision the alert actually drives.
- Prioritize. Rebuild the alerts tied to a real decision. Retire the ones that fire into a dead folder. If nobody acts on an alert, deleting it is a win, not a loss.
- Manage as a team. Add a co-owner to each flow so it does not die when one person changes roles. Build in the correct Environment, and turn on failure notifications so you learn when a flow breaks instead of finding out from an angry colleague.
Takeaway: A retired alert you do not rebuild is a win. Migrate the value, drop the noise.
Governance guardrail: build with IT, not around it
Here is the citizen-dev trap. One enthusiastic month later, a team has hundreds of orphaned flows nobody owns (a figure like “500” is illustrative, but the pattern is real), and that becomes next year’s cleanup project.
Avoid it from day one:
- Use a naming convention so every flow says what it does and which list it touches.
- Give every flow a co-owner, not a single point of failure.
- Reuse patterns instead of reinventing them. Once you learn the trigger-plus-condition shape, use it everywhere.
If you want a repeatable system for this, read keep your flows organized as they grow before you build your tenth flow, not your hundredth.
And when you talk to IT, frame it as partnership: “I am moving off classic alerts. Can you confirm my license, tell me which environment to use, and approve the connectors I need?” That conversation earns you the freedom to keep building.
Takeaway: Governance is not IT slowing you down. It is what lets you keep the flows you build.
Compare the two side by side, so you can see exactly what you are trading up to:
| Capability | Classic SharePoint Alerts | Power Automate |
|---|---|---|
| Conditions (fire only when it matters) | No | Yes |
| Custom formatting and content | No | Yes |
| Route to a specific person or owner | No | Yes |
| Deliver in Teams with action buttons | No | Yes (verify connector tier in your tenant) |
| Multi-step actions (approvals, escalation) | No | Yes |
| Active Microsoft investment | Legacy feature | Yes |
Replacing SharePoint alerts with Power Automate is not busywork forced on you by a retirement notice. It is the moment your notifications finally get a brain.
Do one thing this week: rebuild a single real alert as a flow. Next week, add one condition to it so it stops firing on everything. That is the whole path, and you just started it.
Stay in the loop
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
Related articles
Stop Guessing: Power Automate formatDateTime and the Timezone Trap Nobody Warns You About
Fix wrong dates in your flows for good: Power Automate formatDateTime traps, the convert-first timezone pattern, and a copy-paste reference table.
Stop Guessing: Power Automate Trigger Conditions That Actually Work
Stop debugging blind. Test Power Automate trigger conditions in a Compose action first, then ship four no-code recipes that fire only when they should.