Power Apps Cheat Sheet

Power Apps Formula Reference for Daily Work

Most people building canvas apps in Power Apps eventually hit the same wall: they need to remember which function goes where and how these formulas actually behave in different contexts. I have spent years writing formulas that seem to work in the editor but break when the app ships. The trick is having something to reference quickly rather than hunting through documentation for the third time this week. A Power Apps Cheat Sheet is just a compact reference of the functions, operators, and patterns that actually matter. It saves time when you are staring at a screen trying to figure out why Filter is returning blank results or why LookUp is giving you delegation warnings. I keep mine in a text file and it covers the basics I use every single day. The most useful section covers context transitions. When you put a button inside a gallery, the ThisItem reference changes depending on whether you are inside an ForAll loop or just clicking through records. I learned this the hard way when I built a data entry form that kept using values from the wrong record. The workaround was wrapping my updates in a With function to capture the correct context before making any changes.

Power Apps Cheat Sheet Essentials

Here is what I actually reference without thinking. Filter takes a table and returns a subset, but it does not modify the original. If you need to chain multiple filters, use And or Or operators rather than nesting multiple Filter calls. Nesting creates performance problems because each layer scans the entire table separately. LookUp returns the first matching record. It is faster than Filter when you only need one result, but it has a limitation most beginners miss: it does not play well with complex delegation rules. If your data source is SharePoint or Dataverse and the formula goes over the delegation threshold, LookUp will silently return wrong data. I switch to First(Filter(...)) when I need to be safe, even though it is slower. The Patch function is where most people get confused. It can create or update records, but the syntax changes depending on what you are doing. For updates, you need the existing record as the first parameter. I usually store a reference to the current record in a variable first, then pass that variable into Patch. Without it, the function thinks you are creating a new record and you get duplicates in your datasource.

Data card validation relies on the Errors function combined with Validate. This is not obvious from the default templates. You put Error statements inside the OnChange property of your inputs, then call Validate on the form before submitting. The Form.Error property shows validation messages. I build a custom error display using a dropdown that lists all errors from Errors(MyForm) rather than relying on the built-in red borders, which are easy to miss on mobile devices. Collect and ClearCollect are for local variables, not your main datasource. I see people use ClearCollect to replace proper data connections constantly. The difference matters because local collections do not delegate. If you filter a collection, the entire collection downloads to the device first. For datasets over 500 items, this causes serious performance issues. Use collections only for temporary data that does not need to scale.

Common Patterns That Actually Work

The DisplayMode property controls whether inputs are editable. Setting it to DisplayMode.Edit or DisplayMode.View based on a variable is standard practice, but the trick is combining it with the Required property. A required field that is also hidden or disabled creates confusion for users. I add a check that shows an error message whenever someone tries to submit with a hidden required field. Notify is basic but essential for user feedback. The default timeout is five seconds, which is fine for success messages but too long for errors that need immediate attention. I set the duration parameter to 2000 milliseconds for warnings and 3000 for errors. Success messages can stay at the default. The NotificationType parameter accepts Error, Warning, or Information. Using the wrong type creates awkward UI where error messages look like success confirmations. Gallery delegation is the number one performance problem in Power Apps. When your Filter or LookUp queries exceed the server-side threshold, the app stops working correctly with large datasets. The threshold varies by connector. SharePoint defaults to 500 items. Dataverse is also 500 by default but can be increased to 5000 in the environment settings. I check the warning icon in the formula bar whenever I write a query. Yellow means delegation is partially supported. Red means the formula is completely non-delegable and will fail with more data.

Select versus Notify timing matters when you are building sequential actions. If you run a Patch and then immediately try to read the result, the value might not be available yet. The workaround is wrapping the second action in a Delay function or using the OnSuccess property of the form instead of running code after Patch completes.

Power Apps Cheat Sheet for Debugging

When formulas break, the first thing to check is the data types. Power Apps is strict about types in ways that are not always obvious. Comparing a text field to a number returns false instead of converting automatically. I use Text() to convert numbers to strings before concatenation and Value() to convert text to numbers before arithmetic operations. The Office365Outlook.SendEmailV2 function has limitations that catch people off guard. The CC and BCC fields expect tables of records with Email and DisplayName columns, not simple email addresses. Building this table requires a Collect statement or a ForAll loop. I create a helper function that accepts a semicolon-separated list and converts it to the correct format before sending. Canvas app sizing uses pixels, not percentages for most layout controls. The Width and Height properties are absolute values. When building responsive apps, I calculate sizes based on the screen dimensions using Set statements in the OnVisible property. This approach means the app adjusts when the browser window changes size, rather than staying locked to the design view dimensions.

Error handling in Power Apps follows the Try pattern using OnFailure properties on controls. Instead of checking for errors after every operation, I assign error handlers directly to buttons and forms. This keeps the code cleaner and makes it easier to track where failures happen. The error object contains Code, Message, and Details properties. I usually display the Message property to users and log the Code property for debugging. There is no real way to debug variables across screens except through the App Checker or by adding temporary text labels. I keep a debug panel hidden by default that shows the values of critical variables. When something breaks in production, I toggle the panel visible using a secret button sequence and compare the values against what I expect. This saved me hours tracking down a variable that was being cleared unexpectedly by a gallery refresh.

Limitations to Accept

Power Apps does not support recursive functions. If you need to loop through hierarchical data like organizational charts or bill of materials, you have to flatten the structure first or use multiple queries. This is a fundamental architecture limitation, not a bug. The workaround is storing hierarchy in a denormalized format with parent IDs, then using Filter repeatedly to traverse levels. The UpdateContext function creates local variables that do not persist between screen navigations. If you need state across screens, use Set instead, which creates app-level variables. Mixing these up causes variables to disappear at unexpected times. I keep a list of which variables are local versus app-level in my app settings screen so I can reference it when something goes missing. Real-time collaboration is limited. Two people editing the same record simultaneously can overwrite each other's changes without warning. Power Apps does not provide optimistic locking or conflict resolution out of the box. The workaround is implementing version timestamps and checking for changes before saving. If the timestamp on the server differs from what the user loaded, show an error and ask them to refresh.

Formula complexity has a breaking point. Apps with hundreds of complex formulas in control properties become slow to edit and prone to unexpected behavior. I cap individual formulas at around 500 characters and move anything more complex to custom functions or remote logic through Power Automate. This keeps the app responsive and makes formulas easier to maintain.