June 23, 2025

Power Automate: Are Conditions Case Sensitive?

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:

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 compareapples with apples”:

  1. toLowerfunction – Converts a string to lowercase
  2. toUpperfunction – 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 toUpperfunction , 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 🙂

Photo by Nick Fewings on Unsplash

Manuel

I have 20 years of experience in automation, project management, and development. For the past 6 years, I have been writing for this website, sharing (what I think are) valuable insights and information with readers. I strive to use my expertise to create compelling and informative content that resonates with you and, hopefuly saves you time.

View all posts by Manuel →

Leave a Reply

Your email address will not be published. Required fields are marked *

Mastodon