One of the most common questions when building flows in Power Automate is, “Are conditions case-sensitive?” The super short answer is “Yes,” but that would make for a very poor post.
This seemingly simple question can have significant implications for your automation. If your Flow checks for specific text values and your condition doesn’t account for case sensitivity correctly, your automation might not work as expected.
Let’s explore this topic in depth to understand how case sensitivity works in Power Automate conditions and how you can handle it properly.
The Short Answer
Yes, Power Automate conditions are case-sensitive by default. This means that when you compare string values in conditions, “Hello” and “hello” are treated as different values.
Here’s what this means in practice:
- When you use the condition variable equals value, the comparison is case-sensitive
- When you use the “contains” function, “startsWith” function or “endsWith” function, they are all case-sensitive
- When you use the “is equal” operator in the Condition action, it performs a case-sensitive comparison
Let’s see this in action with some examples.
Conditions in Action
Let’s look at a simple example. Imagine we have a variable called USER_NAME
with the value “Manuel T Gomes“.

If we create a condition to check if this equals “manuel t gomes“ (all lowercase), the condition will evaluate to false
because the cases don’t match.

Here’s the result when we run it:

This case sensitivity applies to all string comparisons in Power Automate conditions.
Using the Equals function
If we use the “equals” function
equals(variables('USER_NAME'), 'Manuel T Gomes') // Returns true
equals(variables('USER_NAME'), 'manuel t gomes') // Returns false
Using Contains Function
Using the “contains” function returns something simular:
contains(variables('USER_NAME'), 'Manuel') // Returns true
contains(variables('USER_NAME'), 'manuel') // Returns false
Using StartsWith and EndsWith Functions
Using the “startsWith” function and “endsWith” function will return the same results:
startsWith(variables('USER_NAME'), 'Manuel') // Returns true
startsWith(variables('USER_NAME'), 'manuel') // Returns false
endsWith(variables('USER_NAME'), 'Manuel') // Returns true
endsWith(variables('USER_NAME'), 'manuel') // Returns false
Making Case-Insensitive Comparisons
Since Power Automate conditions are case-sensitive by default, how can we make case-insensitive comparisons? The solution is to convert both sides of the comparison to the same case (either all uppercase or all lowercase) before comparing them.
Power Automate provides two functions that, although are not for this purpose, can uniform things so that we can compare “apples with apples”:
- “toLower” function – Converts a string to lowercase
- “toUpper” function – Converts a string to uppercase
Here’s how to use them to make case-insensitive comparisons.
Case-Insensitive Equals
equals(toLower(variables('USER_NAME')), toLower('Manuel T Gomes'))
This will return true
regardless of the case in either value because both sides are converted to lowercase before comparison.
Case-Insensitive Contains
contains(toLower(variables('USER_NAME')), toLower('manuel'))
Again, this will return true
regardless of the case in either value.
Best Practices for Handling Case Sensitivity
Here are some recommended practices when dealing with case sensitivity in Power Automate:
Be Consistent with Your Data
Try to be consistent with how you store and work with text data. If you control the input, standardize the case (e.g., always store user names in title case), but when doing the comparisons, you can convert the data “on the fly” to avoid case issues.
Document Your Approach
If you’re building Flows that others will maintain, add comments explaining your approach to case sensitivity so they know why you’re parsing the information before comparing it.
Test with Different Cases
Always test your conditions with different cases to ensure they behave as expected. Also, if you have special characters, validate if the comparison works properly. It should, but you don’t want surprises or bugs popping up since they will be hard to find and fix.
Consider Using Variables for Complex Comparisons
For complex comparisons, consider setting variables or “compose” actions with the transformed values first to make your conditions more readable:
1. Initialize variable "lowercaseUserName" with toLower(variables('USER_NAME'))
2. Initialize variable "lowercaseSearchTerm" with toLower('Manuel')
3. Condition: contains(variables('lowercaseUserName'), variables('lowercaseSearchTerm'))
Another advantage is that, if something goes wrong, you can look at each step and understand the data and fix the issue.
When Case Sensitivity Doesn’t Apply
It’s worth noting that case sensitivity only applies to string comparisons. Other data types in Power Automate aren’t affected by case sensitivity:
- Numbers: Numeric comparisons are always case-insensitive (since numbers don’t have case)
- Booleans: Boolean values (
true
/false
) comparisons are case-insensitive - Dates: Date comparisons are based on their numeric representation, not their string format
For example, these conditions will all evaluate to true
regardless of case:
equals(100, 100)
equals(true, true)
equals(utcNow(), utcNow())
The “true” is a special value and only works lowercase. If you want to learn more about them here’s an article explaining all in detail.
Common Mistakes to Avoid
Here are some mistakes that I see and could be avoided.
Forgetting to Handle Case Sensitivity
The most common mistake is forgetting that conditions are case-sensitive and assuming they’re not. Adding the “toUpper” function , for example, can help us avoid a lot of headaches.
Applying toLower() to Only One Side
Make sure you apply the same case conversion to both sides of the comparison:
// WRONG: Inconsistent case handling
equals(toLower(variables('USER_NAME')), 'Manuel T Gomes')
// CORRECT: Consistent case handling
equals(toLower(variables('USER_NAME')), toLower('Manuel T Gomes'))
Mixing Case Sensitivity Approaches in the Same Flow
Be consistent in your approach. Don’t make some conditions case-sensitive and others case-insensitive without a good reason.
Final Thoughts
Understanding case sensitivity in Power Automate conditions is crucial for building reliable automation. If you’re creating data based on the possibility of it existing, like a folder, for example, not having this validation would generate inconsistent or duplicate information that could be hard to fix and recover.
You can follow me on Mastodon (new account), Twitter (I’m getting out, but there are still a few people who are worth following) or LinkedIn. Or email works fine as well 🙂