If you’re building flows in Power Automate without trigger conditions, you’re wasting API calls and creating noise in your run history. I learned this after deploying a SharePoint approval flow that ran 47,000 times in a single week—45,000 of which were completely unnecessary.

Trigger conditions are expressions that determine whether your flow executes. When properly implemented, they can reduce flow runs by 90% or more. Here’s how to use them effectively with SharePoint.

Trigger conditions use Workflow Definition Language expressions starting with @. Common functions: equals(), not(), and(), or(), contains(), greater(). Here are SharePoint-specific patterns that reduce unnecessary runs.

When an Item Is Created or Modified

Run only when specific person modifies:

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

Run only when specific column changes:

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

Requires versioning enabled on the SharePoint list to access old values.

Run only for specific status:

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

When a File Is Created or Modified

Run only for specific file types:

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

Run only for files larger than 1 MB:

@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

For a document management system I built, flows were triggering on every single file upload regardless of document type. By implementing this trigger condition, I focused only on contract documents that needed approval:

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

This reduced 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 I built, I 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.