Trigger Conditions: For Optimizing Flow Execution

In SharePoint, I love to make flows and processes as efficient as possible. One of the most powerful yet obscure and hidden, features in Power Automate is the trigger condition. In my previous post, you learned about SharePoint One Click Start Approval, where I taught how to create a button that shows next to each file in the SharePoint document library, to click to trigger a flow. With trigger conditions in place, this functionality allows you to create flows that will only run when specific logic conditions are met, saving processing resources and preventing unnecessary flow executions.

What Are Trigger Conditions?

Trigger conditions act as gatekeepers for your flows. While a trigger determines when a flow starts, like when a file is modified, a trigger condition determines if the flow should start based on specific criteria within that trigger event.

For example, rather than having a flow run every time any column of a SharePoint item changes, you can use a trigger condition to ensure it only runs when a specific field like “Status” changes to “Approved.”

Why Use Trigger Conditions?

For SharePoint power users managing complex document libraries and lists, trigger conditions give you a few benefits:

1. Resource Efficiency – Flows only execute when necessary, reducing unnecessary processing
2. Reduced Noise – No more floods of irrelevant flow runs in your run history
3. Precise Workflow Control – Target exact scenarios without complex conditions inside the flow
4. Reduced Flow Failures – Prevent flows from running in situations they weren’t designed to handle
5. Multi-Stage Process Management – Perfect for approval workflows that progress through various stages

The Syntax: How to Write Trigger Conditions

Trigger conditions use expressions that evaluate to true or false. The basic structure looks like this:

@equals(triggerBody()?['ColumnName'], 'ExpectedValue')

Let’s break this down:

• @equals() – A function that checks if two values are the same
• triggerBody()?['ColumnName'] – References a column in your SharePoint list/library
• 'ExpectedValue' – The specific value you’re checking for

One important detail that trips up many users: you must use the internal column name (system name) in trigger conditions, not the display name. For example, a column displayed as “Approval Status” might have an internal name of “ApprovalStatus” without spaces.

Creating Trigger Conditions

While you could write trigger conditions manually if you know the syntax, here’s a clever technique that I use every time:

1. Create a temporary “Do Until” loop in your flow, and for some reason it helps if the flow is in the classic design mode. In my example, the flow will trigger any time a file in this library is modified.

2. Set up the condition exactly as you want it for your trigger condition

3. Switch to “Edit in advanced mode”

4. Copy the expression to your clipboard

5. Delete the do until loop. The only purpose of it was to generate the syntax. Also, you can switch your flow back over to the new designer now.

6. Select you flow’s trigger, go to the Settings tab.

7. In the Trigger conditions section, click the ADD button. Paste the expression into your trigger condition box.

Then, build the rest of the flow. This approach generates the correct syntax for you, eliminating errors and saving time.

Real-World Example: Multi-Stage Approval Process

Let’s look at a practical example of trigger conditions in action. You could build a multiple stage document approval process in SharePoint, which I’ll cover in my next post:

1. A document library has a choice column called “Approval Status” with values: New, Approval 1, Approval 2, Approval 3, Approved, Rejected
2. You create separate flows for each approval stage
3. Each flow has a trigger condition that checks for its specific stage

For example, the first approval stage flow, your trigger condition would be:

@equals(triggerBody()?['ApprovalStatus'], 'Approval 1')

This ensures that the flow only triggers when the status is specifically set to “Approval 1” and not for any other status change.

Advanced Trigger Conditions for Power Users

As you need more complex conditions, you can create more advanced logic:

Using OR Logic

@or(equals(triggerBody()?['ApprovalStatus'], 'Approval 1'), equals(triggerBody()?['UrgentFlag'], true))

This triggers if either the status is “Approval 1” OR the urgent flag is true.

Using AND Logic

@and(equals(triggerBody()?['ApprovalStatus'], 'Approval 1'), not(equals(triggerBody()?['Reviewed'], true)))

This triggers only if the status is “Approval 1” AND the item has not been reviewed.

Checking for Not Equal

@not(equals(triggerBody()?['ApprovalStatus'], 'Rejected'))

This triggers for any status except “Rejected”.

Troubleshooting Trigger Conditions

Even experienced power users can run into issues with trigger conditions. Here are some common pitfalls:

1. Incorrect Column Names – Make sure you’re using the internal system name
2. Case Sensitivity – “Approved” is not the same as “approved”
3. Extra Spaces – Watch for accidental spaces in your condition values
4. Syntax Errors – Missing parentheses or quotes can break your condition
5. New vs. Classic Designer Differences – The new designer sometimes alters the syntax when creating that temporary Do Until loop.

Best Practices for SharePoint Power Users

To get the most out of trigger conditions:

1. Test thoroughly – Create test items and verify your conditions work as expected
2. Document your conditions – Keep a record of the expressions you use
3. Use descriptive flow names – Include the trigger condition in the flow name
4. Create Solutions – Package related flows in solutions for better management
5. Monitor flow runs – Check that your conditions are properly triggering and going down the correct path.

Combining Trigger Conditions with “Get Changes”

To create truly robust flows, combine trigger conditions with the “Get Changes” action. While the trigger condition ensures the flow only starts when the right column contains the right value, “Get Changes” lets you confirm that specific field was the one that changed.

The flow structure would look like:

1. Trigger: When an item is modified (with trigger condition)
2. Action: Get Changes for an item or file
3. Condition: Check if the relevant column has changed or not, like the status for example.
4. Actions: Proceed only if the condition is true

This dual-check approach ensures your flows only run in precisely the right circumstances. In my next post, I’ll show you how to build out the whole process with multiple flows.

Conclusion & Resources

Trigger conditions are a powerful tool for SharePoint power users. They allow you to create efficient flows that only execute when needed. By mastering trigger conditions, you’ll build more reliable flows, reduce unnecessary processing, and create cleaner, more manageable processes.

The next time you find yourself adding complex conditions at the beginning of your flow or dealing with too many unnecessary flow runs, remember that the answer might be as simple as adding a well-crafted trigger condition. Your SharePoint automation will be all the better for it.

Want to take your flows to the next level? Start implementing trigger conditions today, and see the difference in precision and efficiency they bring to your business processes.

Flow when a SharePoint column is updated – This is my post about the action called Get changes for an item or file in SharePoint

Microsoft’s Official documentation about Power Automate triggers

Would you like to learn Power Automate? Check out my very own online 10 hour comprehensive course!