Power Automate in 2026: What to Keep, Change and Check After the Beginner Masterclass

The Problem We Are Solving

If you learned Power Automate from the 2021 beginner masterclass, opening the designer today can make a familiar flow look unfamiliar. Buttons have moved, Copilot may appear beside the canvas, licence names have changed, and advice that was sensible in 2021 may now send you down the wrong path.

That does not mean every old flow needs rebuilding.

The useful question is simpler: which parts of the old session can you keep, which parts should you update, and which details must you check in your own Microsoft 365 tenant before the flow goes live?

This companion to the original 2021 session gives you that decision. It is not another click-by-click course. Use it to review an old flow, or to stop an old tutorial leading you into a new mistake.

The Short Answer

Keep the underlying flow logic. Triggers still start flows, actions still do the work, conditions still split the path, and loops still repeat actions.

Change the way you check the build. The new designer is now the default, but Microsoft still documents the classic designer and allows switching back for compatibility gaps. Copilot can suggest a starting flow in the new designer, but it is optional and may be disabled by your administrator.

Most importantly, check the parts that can create a quiet failure or an expensive surprise: trigger behaviour, loop limits, connections, ownership, failure alerts and licensing.

Keep, Change or Check?

What Matters Before You Edit the Flow

1. A different designer does not automatically mean a broken flow

The new designer is the default experience. It uses a canvas, a configuration pane and, where available, a Copilot pane. Microsoft still supports switching to the classic designer because some flow types and older connection formats are not yet compatible with the new one.

If an old flow opens in the classic designer, do not rebuild it simply to make the screen match a newer tutorial. First test whether the flow still produces the correct result. The designer changes how you edit the flow; the business result is what decides whether it is still usable.

2. Copilot is optional, not a safety check

Copilot can suggest a flow from a plain-English description and help change a flow in the new designer. An administrator can disable it, and some people will not have access.

Even when it is available, treat the result as a draft. Check the trigger, site or mailbox, recipients, connection owner, conditions and failure path yourself. “Copilot created it” is not evidence that the flow is safe to run against live data.

3. Stop unnecessary runs at the trigger

The SharePoint When an item is created or modified trigger reacts to every change to an item. A normal condition later in the flow can stop further actions, but the flow has already started and the call still counts.

A trigger condition checks the rule before the run starts. Use one when the flow should run only after a particular status, flag or value is present.

Do not copy a generic expression containing somebody else’s column name. SharePoint expressions depend on the real internal name and value shape of your column. Build and test the condition against your own list.

4. Check loops before increasing their limits

Microsoft documents a default of 60 iterations and a maximum of 5,000 for an Until loop. It also documents Apply to each as sequential by default, with configurable parallelism from 1 to 50.

A higher number is not automatically better. Before increasing an Until limit, decide what should happen when the stop condition is never met. Before enabling concurrency, confirm that one iteration cannot overwrite or depend on another.

If the loop updates a shared variable, a running total or the same record, keep it sequential unless you have deliberately redesigned the logic.

5. Treat licensing as a flow-specific check

Microsoft 365 licences can include limited Power Automate rights for cloud flows using standard connectors. A Power Automate Premium licence is a user licence with broader cloud and desktop automation rights, including premium connectors. A Power Automate Process licence is capacity assigned to an automation such as a cloud flow or machine.

That is the mechanism. It is not a quote for your tenant.

Before anyone approves a licence, write down:

• every connector used by the flow
• whether the flow is automated, scheduled or instant
• who owns it and, for an instant flow, who runs it
• whether it is associated with a Power App, Dynamics 365 app or solution
• whether an administrator has confirmed the current entitlement and price

The old Per Flow and Per User with Attended RPA names belong to earlier licensing models. Do not use the 2021 table to make a new buying decision.

The 2026 Compatibility Check

Run this against one real flow before you rely on the old masterclass instructions.

Flow record

Ten checks before live use

• The flow opens in a suitable designer. If the new designer cannot open it, the classic designer remains an option while you assess the compatibility gap.
• The trigger points at the correct SharePoint site, list, mailbox, form or schedule.
• A broad SharePoint “created or modified” trigger has a tested trigger condition when the process does not need every change.
• Every connection belongs to an appropriate account and has only the access the flow needs.
• Conditions have been tested with a true result, a false result and missing or unexpected data.
• Until limits and timeouts have an intentional value. Any Apply to each concurrency is safe for the actions inside the loop.
• A failed action follows a visible failure path using Configure run after, such as logging the error and notifying the right person.
• The flow has more than one suitable owner where the process matters to the team.
• The connector and flow context have been checked against current licensing for your tenant.
• The business owner knows the manual fallback and has agreed that the test results are good enough for live use.

Minimal test record

Microsoft recommends recording expected and actual results rather than relying on one successful demonstration.

Recommended Move

Do not begin by rebuilding all six demonstrations.

Choose the old flow that colleagues depend on most. Complete the flow record, run the six tests, and give it one of three decisions:

• Keep: the logic, connections, ownership, licensing and failure path still work.
• Update: the business logic is sound, but the trigger condition, testing, alerting, ownership or licence record needs attention.
• Rebuild or escalate: the flow depends on an unsupported design, an unavailable owner, unclear permissions, an unapproved premium connector or a process that cannot safely tolerate failure.

That gives you something useful to take into a manager or administrator conversation: not “the screen looks different,” but “the flow still works, these three risks remain, and this is what we need before it goes live.”

Evidence Notes

Microsoft documentation supports the platform behaviour in this briefing. It does not prove that a particular flow is safe, correctly licensed or appropriate for your organisation.

• Microsoft documents the new designer as the default while retaining the classic designer for compatibility gaps. Use that to choose an editor—not to assume the flow logic is correct.
• Microsoft documents that trigger conditions can prevent an unnecessary run and its associated API request. The correct expression still depends on your own SharePoint column and value.
• Microsoft documents the current loop limits and concurrency settings. Those numbers do not prove that parallel or long-running processing is safe for your data.
• Microsoft licensing documentation explains user, seeded and capacity licences. Your administrator or licensing partner must confirm the entitlement and price that apply to your tenant and purchasing region.
• Microsoft recommends testing different outcomes, adding failure handling and avoiding reliance on a single owner. Those controls improve supportability; they cannot guarantee that a business process will never fail.