<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Power Automate on Chris Worth</title><link>https://chrisworth.dev/skill-tag/power-automate/</link><description>Recent content in Power Automate on Chris Worth</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 19 Nov 2024 19:15:55 -0600</lastBuildDate><atom:link href="https://chrisworth.dev/skill-tag/power-automate/index.xml" rel="self" type="application/rss+xml"/><item><title>Error Handling in Power Automate: A Comprehensive Guide</title><link>https://chrisworth.dev/posts/power-automate-error-handling-best-practices/</link><pubDate>Tue, 19 Nov 2024 19:15:55 -0600</pubDate><guid>https://chrisworth.dev/posts/power-automate-error-handling-best-practices/</guid><description>&lt;p>A mission-critical approval flow of ours failed silently during a major product launch: no error notifications, no logs, just dozens of unprocessed requests and stakeholders asking why nothing was moving. That&amp;rsquo;s the failure mode error handling exists to prevent, and it&amp;rsquo;s the difference between reliable automation and a career-limiting incident.&lt;/p>
&lt;p>Without error handling, flows terminate unexpectedly, leave processes in inconsistent states, and create cascading failures in dependent systems. I&amp;rsquo;ve seen simple flows without error handling cause major disruptions, while complex flows with proper error management gracefully handle unexpected situations. This is especially important when working with &lt;a href="https://chrisworth.dev/posts/power-automate-trigger-conditions-optimization/">Power Automate trigger conditions&lt;/a> and &lt;a href="https://chrisworth.dev/posts/power-platform-connection-references-guide/">connection references&lt;/a>.&lt;/p></description></item><item><title>Power Automate Trigger Conditions Guide: SharePoint Edition</title><link>https://chrisworth.dev/posts/power-automate-trigger-conditions-optimization/</link><pubDate>Mon, 18 Nov 2024 09:38:03 -0600</pubDate><guid>https://chrisworth.dev/posts/power-automate-trigger-conditions-optimization/</guid><description>&lt;p>If you&amp;rsquo;re building flows in Power Automate without trigger conditions, you&amp;rsquo;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 those runs were completely unnecessary.&lt;/p>
&lt;p>Trigger conditions are expressions that determine whether your flow executes. When properly implemented, they can reduce flow runs by 90% or more. Here&amp;rsquo;s how to use them effectively with SharePoint.&lt;/p></description></item><item><title>Use OData Filtering in Power Automate Flows</title><link>https://chrisworth.dev/posts/power-automate-odata-filtering-performance-guide/</link><pubDate>Mon, 18 Nov 2024 09:22:44 -0600</pubDate><guid>https://chrisworth.dev/posts/power-automate-odata-filtering-performance-guide/</guid><description>&lt;p>Power Automate&amp;rsquo;s own &amp;ldquo;Get items&amp;rdquo; action nudges you toward the wrong pattern by default: pull the whole list, then filter it inside the flow. It looks harmless on a small list and hits throttling limits the moment a list has real volume behind it. OData filtering, applying the filter at the data source through the Filter Query field, fixes that at the root instead of working around it downstream.&lt;/p>
&lt;p>When I built our organization&amp;rsquo;s document approval system, retrieving thousands of items from SharePoint frequently caused timeouts and throttling errors. By implementing precise OData filters, we reduced processed items by 95% and eliminated those issues entirely. The &lt;a href="https://www.odata.org/">Open Data Protocol (OData)&lt;/a> queries and filters data directly at the source (whether SharePoint lists or Dataverse tables), improving performance and reducing what your flow processes.&lt;/p></description></item></channel></rss>