Both let you branch your flow based on a value. The difference is how many branches you’re dealing with and how readable your flow stays once it’s built, or how readable it stays before you have to open it again in six months and wonder what past you was thinking. WHEN TO USE A CONDITION A Condition checks one thing and gives you two outcomes, yes or no, true or false. It’s the right tool when you’re checking something like whether a value is greater than zero, whether a field is empty, or whether two values match. Conditions can be nested inside each other for more complex logic, but nest more than two or three deep and your flow turns into a choose your own adventure book nobody asked for. That’s usually the sign you’ve reached for the wrong tool. WHEN TO USE A SWITCH A Switch checks one value and lets you branch into as many outcomes as you need, each one running its own separate set of actions. It’s the right tool when you’re checking something like a status field, a record type, or a category, where there are several possible values and each one needs different handling. Instead of nesting four or five Conditions to handle each possible value, a Switch gives you one clean branch per outcome sitting side by side. Much easier to read, and much easier to add a new case to later without untangling existing logic or apologising to whoever inherits the flow. A PRACTICAL EXAMPLE Say you’re processing a support ticket and the next steps depend on its priority. Low, Medium, High, Critical. Nesting that in Conditions would mean checking if it’s Low, if not check if it’s Medium, if not check if it’s High, and so on, basically playing twenty questions with your own flow. A Switch on the Priority field gives you four clean branches instead, each one obvious at a glance. If you’re only ever checking one thing with two outcomes, Condition is fine. The moment you’re checking one value against three or more possible outcomes, reach for a Switch instead and save yourself the headache.

Variables are great. But a lot of people reach for them out of habit when they only need to store or build a value once and reference it later. Use a Compose instead. WHAT IS COMPOSE Compose is an action that takes any input, a value, an expression, or a combination of both, and outputs it for you to reference elsewhere in your flow. No initialising, no setting, no type to declare. You just put the value in and use it. WHY COMPOSE OVER A VARIABLE Variables have to be initialised at the top of your flow before you can use them. That is an Initialize Variable action, then a Set Variable action where you actually need it. Two actions. Compose is one action placed exactly where you need it. Fewer actions means fewer API calls to the Power Automate runtime on every single run. For a value you only need to build once, a Variable is unnecessary overhead. Compose also accepts anything. String, integer, object, expression. No type to declare and no type mismatch errors to debug later. WHERE VARIABLES STILL WIN If you need to update a value inside an Apply to Each loop, you need a Variable. Compose outputs are fixed once the action runs. You cannot overwrite a Compose mid-flow the way you can with a Set Variable action. The rule of thumb is simple. If you are setting something once and referencing it later, use Compose. If you need to update a value as your flow progresses, use a Variable. Have you been initialising Variables at the top of every flow? Drop a comment below.

WHAT’S HAPPENING When you select a field from dynamic content inside a List Rows action, Power Automate wraps your next step in an Apply to Each automatically. You didn’t add it. You didn’t ask for it. It just appears, which is Power Automate being helpful in the most annoying way possible. If you know only one row will ever come back, you don’t need it. SET THE ROW COUNT TO 1 On your List Rows action, set the Row Count to 1. This tells Power Automate to stop after the first match rather than pulling everything back. Less data, faster flow, less to go wrong. USE AN EXPRESSION INSTEAD Rather than picking the field from dynamic content, type this into an expression instead: body(‘List_Accounts’)?[‘Value’]?[0]?[‘pphub_status’] Here’s what each part means: body(‘List_Accounts’) is the name of your List Rows step. Swap it for whatever yours is called. ?[‘Value’]?[0] grabs the first item in the returned array. Index 0 is always first. ?[‘pphub_status’] is the internal name of the field you want. Swap for yours. WHY BOTHER For a single result, skipping the Apply to Each makes your flow easier to read and debug. It’s overhead your flow simply doesn’t need. Have you been caught out by an unwanted Apply to Each before? Drop a comment below.

We'd love for everyone to get to know each other. Drop a comment below and tell us a bit about yourself. Where are you based, what do you work with day to day, and how long have you been in the Microsoft ecosystem? We'll kick things off first. We're The Power Platform Hub team. We've been working in the Power Platform and Dynamics 365 space for a collective 15 years across a range of industries and project sizes. We built the Hub because we kept seeing the same problem: nowhere decent to get a straight answer when you needed one, and no single place to get important Microsoft updates without wading through noise. That's what this place is for. And this is very much an evolving community. If there's something you'd like to see here, let us know. Now over to you.

If you hold any Power Platform or Dynamics 365 certifications, or you're planning to take one, this is worth reading. Microsoft is retiring several key credentials this year and replacing them with AI-focused alternatives. Here's the full picture: Retiring 30 June 2026 - PL-500: Power Automate RPA Developer Associate. No direct replacement announced. - MB-240: Dynamics 365 Field Service Functional Consultant Associate. No direct replacement announced. - PL-600: Power Platform Solution Architect Expert. No direct replacement, but see AB-100 below. - MB-335: Dynamics 365 Supply Chain Management Functional Consultant Expert. No direct replacement, but see AB-100 below. - MB-700: Dynamics 365 Finance and Operations Apps Solution Architect Expert. No direct replacement, but see AB-100 below. - Applied Skills: Create and manage model-driven apps with Power Apps and Dataverse. Replaced by the new Applied Skills: Build an agent-first app credential. Retiring 31 July 2026 - MB-280: Dynamics 365 Customer Experience Analyst Associate. Replaced by AB-210: Dynamics 365 Sales AI Consultant Associate. Retiring 31 August 2026 - PL-200: Power Platform Functional Consultant Associate. Replaced by AB-410: Intelligent Applications Builder Associate. They are being replaced by new AI-focused certifications launching from April 2026: - AB-410: Intelligent Applications Builder Associate. Replaces PL-200. Beta and training available April 2026, exam live June 2026. - AB-210: Dynamics 365 Sales AI Consultant Associate. Replaces MB-280. Beta May 2026, exam live June 2026. - AB-620: AI Agent Builder Associate. For developers and architects building production-ready Copilot Studio agents and multi-agent solutions. Beta April 2026, exam live June 2026. - AB-250: Dynamics 365 Contact Center AI Engineer Associate. For contact centre engineers working with Dynamics 365 Contact Center. Beta June 2026, exam live August 2026. - AB-100: Agentic AI Business Solutions Architect Expert. Microsoft's new flagship expert-level certification covering agentic architectures and AI-driven solution design. Already available. Not a direct replacement for retiring expert certs, but Microsoft specifically recommends it as the next step for anyone holding or working towards PL-600, MB-700, MB-335, MB-240, or PL-500. Note: you also need a current associate-level certification to earn AB-100.