Introduction

If you’re building flows in Power Automate, you’ve probably experienced the frustration of having them run unnecessarily, cluttering your run history and potentially hitting your organization’s API limits. That’s exactly why trigger conditions exist—to give you precise control over when your flows execute.

I’ve spent years optimizing flows across different organizations, and trigger conditions have consistently been one of the most powerful yet underutilized features in Power Automate. This guide focuses on trigger conditions with an emphasis on the SharePoint connector, providing you with the knowledge to create more efficient and targeted flows.

Why Trigger Conditions Matter

I learned the importance of trigger conditions the hard way. After deploying a SharePoint-based approval flow across our organization, we quickly discovered it was running unnecessarily thousands of times per day. The culprit? Missing trigger conditions.

Properly implemented trigger conditions can:

  • Reduce Flow Runs: Only execute your flow when truly needed, saving your organization’s API limits.
  • Improve Performance: Fewer unnecessary runs means faster response times for legitimate triggers.
  • Simplify Monitoring: When analyzing flow runs, you’ll only see relevant executions.
  • Reduce Error Rates: Fewer runs means fewer opportunities for failures.

The difference between a well-optimized flow and one without proper trigger conditions can be dramatic—I’ve seen reductions of 90% or more in unnecessary flow executions.

Basic Concept

A trigger condition is an expression that evaluates to either true or false. When true, the flow runs; when false, the flow is skipped. This helps reduce unnecessary flow runs and can significantly optimize your Power Automate usage.

Syntax

Trigger conditions in Power Automate use expressions based on Workflow Definition Language (WDL) functions. The basic syntax is:

@functionName(parameter1, parameter2, ...)

Important Note: Every trigger condition must start with the @ symbol.

Examples of functions include:

  • equals()
  • not()
  • and()
  • or()
  • greater()
  • less()
  • contains()
  • startsWith()
  • endsWith()
  • empty()
  • int()
  • string()
  • float()
  • convertTimeZone()

SharePoint-specific Trigger Conditions

1. When an Item Is Created or Modified

This is one of the most common SharePoint triggers. Here are some useful trigger conditions:

Run Only When a Specific Person Modifies an Item

Using the user’s display name:

@equals(triggerBody()?['Editor']?['DisplayName'], 'John Doe')

Alternatively, using the user’s email for reliability:

@equals(triggerBody()?['Editor']?['Email'], '[email protected]')

Run Only When a Specific Column Is Modified

To check if a specific column, e.g., Status, has changed:

@not(equals(triggerBody()?['Status'], triggerBody()?['[email protected]']))

Note: Access to @odata.oldValue may require versioning to be enabled on your SharePoint list. This expression compares the current value of the Status field to its previous value.

Run Only for Items with a Specific Status

For example, run the flow only for items where Status equals Approved:

@equals(triggerBody()?['Status'], 'Approved')

2. When a File Is Created or Modified

Run Only for Specific File Types

For example, to run only for Word documents:

@endsWith(triggerBody()?['FileLeafRef'], '.docx')

Run Only for Files Larger Than a Certain Size (in Bytes)

For example, run for files larger than 1 MB (1,048,576 bytes):

@greater(triggerBody()?['Length'], 1048576)

Note: The property Length typically contains the file size in bytes.

3. When an Item Is Deleted

Run Only When Items Are Deleted from a Specific Folder

For example, run when items are deleted from the SpecificFolder:

@startsWith(triggerBody()?['FileRef'], '/sites/YourSite/SpecificFolder/')

Note: Ensure you provide the correct server-relative URL to your folder.

Advanced Techniques

1. Combining Multiple Conditions

Use logical operators to combine multiple conditions:

  • and()
  • or()
  • not()

Example: Run when Status is Approved and Priority is High:

@and(
  equals(triggerBody()?['Status'], 'Approved'),
  equals(triggerBody()?['Priority'], 'High')
)

2. Working with Date/Time Fields

When dealing with date/time fields in SharePoint, you can compare date values directly. However, it’s important to ensure that both dates are in the same format and time zone.

Example: Check if the DueDate is before now:

@less(
  convertTimeZone(triggerBody()?['DueDate'], 'UTC', 'UTC', 'yyyy-MM-ddTHH:mm:ssZ'),
  utcNow()
)

Note: Be mindful of time zones when working with date/time fields. Use convertTimeZone() if necessary to ensure consistency.

3. Using Expressions

You can use expressions in your trigger conditions. For example, check if Quantity exceeds a minimum threshold (e.g., 10):

@greater(
  int(triggerBody()?['Quantity']),
  10
)

4. Checking for Column Changes

To check if a specific column has changed, compare the current value to the previous value using @odata.oldValue:

@not(
  equals(
    triggerBody()?['Status'],
    triggerBody()?['[email protected]']
  )
)

Note: This compares the current value of the Status field to its previous value.

5. Working with Person Fields

Person fields in SharePoint require special handling.

Check if the AssignedTo Field Is Not Empty

@not(empty(triggerBody()?['AssignedTo']))

Check if AssignedTo Is Assigned to a Specific User

@equals(triggerBody()?['AssignedTo']?['Email'], '[email protected]')

6. Handling Null Values and Missing Fields

It’s important to handle potential null values or missing fields to avoid errors.

Check if Status Is Approved, Accounting for Null or Missing Values

@and(
  not(empty(triggerBody()?['Status'])),
  equals(triggerBody()?['Status'], 'Approved')
)

Check if CustomField Exists and Equals ExpectedValue

@and(
  contains(triggerBody(), 'CustomField'),
  equals(triggerBody()?['CustomField'], 'ExpectedValue')
)

Note: The contains() function checks if the CustomField exists in the trigger body.

7. Working with Lookup Fields

Lookup fields in SharePoint contain more complex data. Here’s how to handle them:

Check if the Department Lookup Field Is Set to HR

@and(
  not(empty(triggerBody()?['Department']?['Value'])),
  equals(triggerBody()?['Department']?['Value'], 'HR')
)

Explanation:

  • The not(empty()) function ensures the Department field has a value.
  • The equals() function compares the value of the Department field to HR.
  • The and() function ensures both conditions are met.

Real-World Scenarios

Document Approval Workflow

In our organization’s document management system, we had flows triggering on every single file upload regardless of document type. By implementing this trigger condition, we focused only on contract documents that needed approval:

@and(
  startsWith(triggerBody()?['FileLeafRef'], 'Contract-'),
  endsWith(triggerBody()?['FileLeafRef'], '.docx'),
  equals(triggerBody()?['ApprovalStatus'], 'Pending')
)

This reduced our flow runs from hundreds per day to just the dozen or so contract uploads that actually needed processing.

HR Onboarding Process

For an employee onboarding system, we needed to trigger specific flows only when an employee’s status changed to “Hired” for the first time:

@and(
  equals(triggerBody()?['EmployeeStatus'], 'Hired'),
  not(equals(triggerBody()?['[email protected]'], 'Hired'))
)

This prevented the onboarding flow from executing multiple times if other fields in the employee record were updated later.

Troubleshooting Guide

When your trigger conditions aren’t working as expected, follow these steps:

  1. Verify Syntax: Double-check for missing parentheses, quotes, or operator typos.

  2. Test with Simpler Conditions: Replace your complex condition with something basic like @equals(1,1) to confirm the trigger condition functionality works.

  3. Examine Your Data: Use Flow outputs to verify what triggerBody() contains—the property names and structure might not be what you expect.

  4. Watch for Capitalization: SharePoint column internal names might differ from display names. Use triggerBody() without conditions to see the exact property names.

  5. Check Data Types: If comparing numbers, ensure you’re comparing the same types by using int() or float() functions.

I once spent hours debugging why a condition wasn’t working, only to discover a SharePoint column named “ApprovalStatus” was actually coming through as “Approval_x0020_Status” in the trigger body!

Best Practices

  1. Keep It Simple: Start with simple conditions and build up complexity as needed.
  2. Test Thoroughly: Always test your trigger conditions with various scenarios to ensure they work as expected.
  3. Document Your Expressions: Keep a record of all trigger conditions used, along with explanations. This aids in maintenance and troubleshooting.
  4. Monitor Performance: Complex trigger conditions can impact performance. Use the Power Automate analytics feature to monitor your flows’ run history and duration.
  5. Use Trigger Conditions Judiciously: While powerful, overuse of trigger conditions can make flows harder to maintain.
  6. Handle Null Values and Missing Fields: Always account for potential null values or missing fields in your conditions to avoid runtime errors.
  7. Use @odata.oldValue to Compare Values: When you need to check if a field has changed, compare the current value to the previous value using @odata.oldValue.
  8. Test Each Expression Individually: Before deploying the trigger condition in a production environment, test it in a controlled setting to ensure it behaves as expected.

Performance Monitoring

To monitor the performance of your flows:

  1. Go to the Power Automate portal (https://flow.microsoft.com).
  2. Select your flow.
  3. Click on the Analytics tab.
  4. Here you can view run history, success rate, and average duration.

For more detailed monitoring, consider using Azure Application Insights. You can integrate Power Automate with Application Insights for advanced telemetry and diagnostics.

Common Pitfalls and Solutions

  1. Case Sensitivity: SharePoint column names are case-sensitive in trigger conditions. Double-check your column names.
  2. Data Types: Ensure you’re comparing the correct data types. Use functions like int(), string(), or float() to convert when necessary.
  3. Null Values: Always handle potential null values to avoid errors. Use functions like empty() and logical operators like and() and not() as demonstrated in the “Handling Null Values and Missing Fields” section.
  4. Complex Data Types: For lookups or person fields, access properties correctly. Refer to the examples in the “Working with Lookup Fields” and “Working with Person Fields” sections.
  5. Time Zones: Be aware of time zone differences when working with date/time fields. Use utcNow() and explicitly format dates to avoid inconsistencies.
  6. Throttling: While trigger conditions themselves don’t directly impact throttling, optimizing them can reduce unnecessary flow runs, indirectly mitigating throttling issues.

Conclusion

Mastering trigger conditions in Power Automate is a journey worth taking. The techniques we’ve covered in this guide have helped me create more efficient, targeted, and reliable flows—and they can do the same for you.

Remember these key points:

  • Trigger conditions save resources by preventing unnecessary flow runs
  • Always handle null values and data type mismatches
  • Test thoroughly with real data before deployment
  • Document your conditions for future maintenance

As you implement these practices in your own flows, you’ll likely discover unique challenges specific to your data and processes. Don’t hesitate to experiment and adapt these techniques to your specific needs. The Power Platform community is also an excellent resource for troubleshooting and ideas.

What’s your next step? I recommend reviewing your most frequently running flows to identify opportunities for optimization with trigger conditions. Even simple conditions can dramatically reduce unnecessary runs and improve your overall flow performance.