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.