When working with SharePoint data in Power Automate, filtering your dataset efficiently is key to building optimized workflows. One of the most powerful ways to filter SharePoint data is by using oData filter queries  in the Get Items  action. This post will walk you through different examples of filtering various column types  and using logical operators  to refine your results. If you want to see all of the concepts from this blog post in action then check out the full length video where we go hand on with these and other examples of oData filtering. You can find the YouTube step-by-step video here: Filter SharePoint Data in Power Automate with oData Understanding oData Filter Queries in Power Automate oData (Open Data Protocol) is a standard query language that enables filtering and querying data efficiently from multiple data sources, including SharePoint, Dataverse, and SQL Server. When used in Power Automate, it allows you to retrieve specific records without pulling unnecessary data, improving performance and efficiency. For the examples in this post, we will be using the Power Automate Cloud Flow action "Get Items"  to filter SharePoint list data. However, it’s important to note that oData queries are widely applicable across various platforms, including Microsoft Dataverse, SQL Server, and even third-party services that support the oData standard. Learning how to construct and apply these queries will benefit you in multiple automation and data retrieval scenarios. An example of the Get Items action with an oData Filter Query for the Created by field in SharePoint Filtering Different SharePoint Column Types Each SharePoint column type has its unique characteristics and filtering them requires different approaches. Below are practical examples of how to filter single-line text, choice, lookup, number, and date columns  using oData. 1️⃣ Filtering a Single Line Text Column For a text-based column , you use the eq (equals) operator. The column name is case-sensitive and must match exactly as it appears in SharePoint. Example: Title eq 'Project X' This retrieves all SharePoint list items where the Title column is Project X . 2️⃣ Filtering a Choice Column Choice columns require the same syntax as text columns. Ensure you use single quotes around the value. Example: Department eq 'Sales' This filters all items where the Department  choice column is set to "Sales." 3️⃣ Filtering a Multi-Choice Column Multi-choice columns can contain multiple values, so filtering them requires an exact match. Example: Skills eq 'Power BI' This filters records where the Skills  column contains exactly "Power BI." For filtering multiple selections: Skills eq 'Power BI' or Skills eq 'Excel' This retrieves items where Skills  include either Power BI  or Excel. Pro Tip:  If you're unsure of a column’s internal name, check the List Settings  in SharePoint or inspect the raw JSON output from a Get Items  action. 4️⃣ Filtering a Lookup Column Lookup columns reference values from another list. The default way to filter is using the ID  of the lookup record. Example: DeptLookUp eq 3 This retrieves all records where the Department lookup field  has an ID of 3. If you prefer filtering by the title  of the lookup field: DeptLookUp/Title eq 'Marketing' This pulls items where the related department’s Title  is "Marketing." 5️⃣ Filtering by Number Values Number fields support operators such as eq, gt, lt, and le. Example: Age gt 30 This retrieves all items where the Age  column is greater than 30. To filter within a range: Age gt 30 and Age lt 50 This gets records where the age is between 31 and 49. 6️⃣ Filtering by Date Values Dates in SharePoint require a special format: YYYY-MM-DDThh:mm:ss. Example: HireDate ge '2020-01-01T00:00:00' This retrieves employees hired on or after January 1, 2020. To find records within a year: HireDate ge '2022-01-01T00:00:00' and HireDate le '2022-12-31T23:59:59' This filters records where HireDate  falls within 2022. 7️⃣ Filtering by Created By (Author) Field The "Created By" field in SharePoint is internally referred to as Author. To filter based on this field, you need to use /Email or /Title depending on whether you want to match an email or a display name. Example: Author/Email eq 'user@example.com' This retrieves all records created by user@example.com . If filtering by display name: Author/Title eq 'John Doe' This pulls items where the Created By  field matches "John Doe." Be mindful that display names are not always unique. Using Logical Operators: and, or, Parentheses oData allows for complex filtering by combining multiple conditions using and, or, and parentheses. Make sure you use them all lower case. Combining Filters with AND Department eq 'HR' and Age gt 25 This retrieves employees from the HR department who are older than 25. Combining Filters with OR Skills eq 'Power Automate' or Skills eq 'SharePoint' This retrieves records where employees have either Power Automate  or SharePoint  skills. Grouping Filters with Parentheses (Department eq 'IT' or Department eq 'Finance') and Age lt 40 This retrieves all employees from IT or Finance  departments who are younger than 40. Conclusion oData filtering in Power Automate is a powerful way to query SharePoint data efficiently. Understanding how different column types work and applying the correct operators ensures that your workflows run faster and return the most relevant data. If you need help with this, remember we have support services where someone will hop on a screenshare with you for as little as 30 minutes to help. Just hist the Contact button and let us know how we can help.

Covering Text Inputs, Number Inputs, Text Labels, and Buttons Modern Controls are all of the rage but as long-time builders we often find ourselves asking what is new and what is different. Below I have offered some overall thoughts and documented three of the most common controls in detail. Hopefully, this helps you quickly bridge the differences between the two. And yes, Input Controls have a lot of notes. They are drastically different, whereas labels and buttons are mostly visually different. If you want a more hands on look at these differences then be sure to check out my Youtube video Modern vs Classic Controls in Power Apps - Buttons, Text Inputs, and Text Labels Finally, if you are having a hard time with the different properties for these controls, you can download this guide with all of the properties mapped out using the fancy link below. It includes each Property name and description, what control it is applicable for, and if it was renamed from Classic to Modern what the new or old name was. Lots of little details to make your life easier. Example for the Inputs: Download the guide⬇️ General Notes of Differences for Modern and Classic Controls in Power Apps Below is a breakdown of just things to know going into using Modern Controls with Power Apps. Hopefully these little notes help you pull out your hair a bit less when you trip over things like OnSelect being gone for most controls. Styling : Modern Controls follow Fluent UI guidelines for styling, offering consistent themes and polished looks. At the expense of not being able to manually set a lot of the visual properties yourself. For example, properties like DisabledFill, HoverColor, and PressedBorderColor that were available in Classic Controls are currently not present in Modern Controls. This means you'll lose some of the fine-grained control over the appearance of your app in different interaction states. For example: I often would set the visual properties of disabled mode in a control to very specific colors to achieve a desired effect for one control in classic controls, this level of customization is no longer available. Font Sizing : Modern uses pixels while Classic uses points, often leading to inconsistent font sizes across controls. So basically, when you start adding Modern Controls be prepared for everything to be smaller, you will need to rethink what are your default font sizes and such. Themes : The Modern Controls use the new theme engine. It is kind of configurable but will add to your confusion in the short term. To view/configure what you can with themes look on the Left Rail and click … to find Themes. Then to manipulate per control click on the control and at the bottom of the Properties panel on the right you will see similar to below. Accessibility : Classic Controls include more traditional accessibility features such as Live and Role, while Modern Controls are progressively incorporating these features. One of the goals of Modern Controls is to be more accessible. OnSelect isn't as common : With Classic Controls just about every control had an OnSelect property, making them all "clickable". That is not the case with Modern Controls, if you want something to be clickable you are most likely going to need to use a Button, Icon, or Image control.  Reset property is gone : If you got used to using a variable to trigger mass resets, sorry that isn't possible. Back to Reset(ControlName)  being the only option. Avoid mixing and matching : Modern Controls and Classic Controls are so different, especially visually, it is basically impossible to combine them in the same app and have it look nice. So, commit to one or the other. Text and Number Input Control Differences Quick note. This one is a bit odd because the Classic Text Input has been replaced by two controls. Text Input and Number Input are separate controls that are similar but have nuance difference. Most of which is covered below.  Trigger Behavior : Classic uses DelayOutput; Modern replaces this with TriggerOutput offering options like FocusOut, Delayed, and Keypress. While this is a nice change, you will need to think about how your OnChange is triggered, each of those 3 options have their own quirks to meet specific scenarios and none exactly line up with how it worked in Classic Controls. Clear Button and Spell Check : Classic included a built-in clear button and the ability to enable Spell Check. Disabled vs. Enabled : With Classic Controls a Text Input in view mode looked exactly like a label, which made it easy to reuse the control for display-only purposes. Now a view mode Text Input looks exactly like an edit mode Text Input, which isn’t ideal and is confusing to users. You can't easily reuse the same control for editable and read-only scenarios without causing confusion. Which would change how I designed the look of a lot of apps over the year.  Number Input is Separate : In Classic, you often used a Text Input with formatting rules to handle numbers. In Modern, there's a dedicated Number Input control with its own properties like Min, Max, Step, and Precision. This makes numeric input more flexible, but also means managing a new set of behaviors and edge cases. Number Input : The control now has an up and down increment arrow you can use to adjust the value in the control. It is kind of hard to see. If you want to get rid of it set the Step property to 0. Not very obvious. Value vs. Text : Number Input uses a Value output property instead of Text. This can be helpful for calculations but may require some refactoring if you're used to string-based logic. This means to get the number out of a Modern Number Input Control you would use NumberInput1.Value where as with a Text Input you would use TextInput1.Text. Overall : Lots of change with Inputs plus the fact that number inputs are the same but different will probably cause you a bit of confusion for a while. But don’t worry, once it clicks, it will all make sense. Text Label Control Differences OnSelect : Worth repeating, it is gone, as that one really frustrated me. If you want to simulate an interactive label, one workaround is to overlay a transparent button on top of the label and use its OnSelect instead. Visual Everything:  The alignment, the size, the padding, everything is different. It is fine, just be ready to reconsider the look and feel as you add these new labels. If you are new to Power Apps then not a big deal, you will never know the difference.  Below they are both using default size and both are against the top of the screen. Font size and vertical align are easy to see differences, but there are plenty more. Overall : Functionally is very much the same, just visually different. Button Control Differences Icons : Modern Controls allow inline icons with Icon, IconRotation, IconStyle, and Layout; Classic does not. Hover and Pressed States : Classic includes HoverFill, PressedFill, DisabledFill, and more; these are currently missing in Modern. Overall : Good news, a button is basically still a button, just with different sizing and style.

Ever felt the frustration of trying to convert various image types into a PDF without shelling out for a "Premium" action in Power Automate? You're not alone! But guess what? We've cracked the code. Dive into our innovative technique that leverages an HtmlText control to generate HTML, enabling Power Automate to seamlessly create PDF documents. And the best part? This method effortlessly incorporates images from a SharePoint list image column. Ready to revolutionize your workflow? Let's get started! SharePoint list with image columns First, you’ll need a SharePoint list with some image columns. We can insert some images into the list, either JPEG or PNG. Then we connect this list as a data source for our app. Screen with HtmlText and Image controls Next create a blank app with Power Apps. Add some Image controls to the screen (corresponding with the number of images you want to use) and an HtmlText control. We’re going to add some code (that refers to the image controls) that runs OnVisible property of the screen. The image controls are tied to the SharePoint list images, either through a variable or a LookUp based on the ID or another “key” column (our example is the ParentID column). How we harness JSON and extract base64 The first thing we do is get the JSON string of the image via the JSON function, then we determine the image format (PNG or JPEG), then we set a formatting variable for string manipulation to extract the base64 string from the JSON string, finally we assign the base64 string to a variable that we can use in our HTML. That’s the key this technique! Screen OnVisible code Let’s break down the code in the screen OnVisible, line-by-line. Then we’ll put it all together once we’ve explained it. In this section, our examples show the code as though we’re pulling two images into the HtmlText control, but the steps below just show you how to do it for a single image. (You can repeat this technique for multiple images in your HtmlText control.) First, we use a With function pointing towards an Image control. You could simply insert the JSON formula into your variable calculation for varImage1, but you’d have to do it 2x. The With function is more performant, as it’s similar to defining a context variable. With({jsonImage1: JSON(Image1.Image, JSONFormat.IncludeBinaryData)}, Next we use a series of Context variables. Why? Simply because we don’t have to reset them (since they don’t reside in memory beyond the active screen). Since the calculation of subsequent variables depends on the previous variable calculations, we need to use the UpdateContext formula several times, in a sequence. Our first Context variable is for the image format. It looks for “.png” and “.jp” in the image text string within the JSON data. How can you view this text? Just insert a Text or Label control onto your screen, and make your Image1.Image the Text property, and you can see the complete text string. Within that text string, you’ll be able to see the image file suffix, but you must search for it. So, in the formula, we use the Find formula to look for the image format. The Find formula will either return blank or an integer, so we use a greater than operator to see if the value is greater than 0 to determine what type of image it is (PNG, JPEG or “unknown”). Then we use this value in the next context variable. Additionally, this variable also goes into the HtmlText control in the HTML text string. This is our “Format” variable: UpdateContext({varImage1Format: If(Find(".png", Step1Image.Image) > 0,"png", If(Find(".jp", Step1Image.Image) > 0,"jpeg","unknown"))}) Our next variable helps us modify our text string to extract the base64. PNG files have base64 code beginning with “iVBOR” whereas JPEG base64 code begins with “/9j/”, so we need to feed different values into our Mid function when we’re extracting the base64 code from the JSON string of the image control. We could have used a single If function, but we wanted to have a way to confirm that the item is a JPEG. We use this variable as input into our next variable that extracts base64. This is our “String manipulation” variable. UpdateContext({varImage1Code: If(varImage1Format = "png", 24, If(varImage1Format = "jpeg", 25, 24))}), In our next variable, we slice off everything we don’t need to create the base64 code that our HtmlText control can recognize as an image. This is our “base64” variable. UpdateContext({varImage1: Mid(jsonImage1, varImage1Code, Max(Len(jsonImage1) - varImage1Code, 0))}) That’s it for the OnVisible coding, here’s the complete block of code (including some remarks): With({jsonImage1: JSON(Image1.Image, JSONFormat.IncludeBinaryData)}, //Image1Format looks for .png or .jp(eg) in the text string to determine the format for the HTML UpdateContext({varImage1Format: If(Find(".png", Step1Image.Image) > 0,"png", If(Find(".jp", Step1Image.Image) > 0,"jpeg","unknown"))}), //Image1Code bases the position for the Mid function to check: 24 for png and 25 for jpeg UpdateContext({varImage1Code: If(varImage1Format = "png", 24, If(varImage1Format = "jpeg", 25, 24))}), UpdateContext({varImage1: Mid(jsonImage1, varImage1Code, Max(Len(jsonImage1) - varImage1Code, 0))}) Code for the HtmlText control We inserted an HtmlText control on our screen. Since we’re just using the text from this control in our Power Automate flow, it’s not necessary to make it visible, but we did, just so we could ensure that the images render properly before initiating the flow to turn it into a PDF. To make the image format dynamic, we used our varImage1Format variable. The base64 text string from the image is in varImage1. This is how we added the code inside of an HtmlText control to display the image: "" In our example above, the image on the left with the cat is a JPEG and the image on the right with the tank is a PNG. Both render properly in the HtmlText control. (Your HTML can include text, tables, and dynamic content other than your images, but this post focuses on the image piece.) Now you have HTML text that you can submit to Power Automate to build your PDF. Let’s look at how to build your PDF flow. Create the PDF flow When you build the flow, if you’re not already in a solution, you should initialize the flow from Power Apps to link it to the app. Else, if you create it straight from Power Automate, you’ll need to add both app and flow into a solution so that you can add the flow to your app. Once you’ve created the flow and it’s tied to your app, you can then enter the flow from Power Automate to continue editing. Let’s go through the flow. The trigger is “When Power Apps calls a flow (V2)”. Your input must include the text input including the HtmlText from your HtmlText control. Then use a OneDrive (for business) “Create file” action. This action will create a temporary HTML file in OneDrive that you can use for the next action. For the “File Name” you can use something like test.HTML. For the “File Content” use the dynamic content for the HTML text input from Power Apps. Next, we use a OneDrive (for business) “Convert file” action. The “File” input is the Id dynamic output from the “Create file” action. Ensure you select PDF (default) as the “Target type”. This step does not create the file; it merely reformats the HTML into PDF. You must save the code next. To save the PDF code, use a “Create file” SharePoint action. This action adds your new PDF to a document library so you can refer to it from your app. You can use dynamic content for the File Name or simply create a name with a suffix of “.pdf”. If you don’t have a unique file name, each subsequent time your flow runs it will fail, because the SharePoint “Create file” action must patch a unique File Name. In the formula below, using the concat function, utcNow() provides a unique prefix, and then we add ‘.pdf’ to it to correctly identify the file: concat(utcNow(),’.pdf’) Optionally, you can include a “Respond to a Power App or flow” step that includes a link to your new document. You can title a text output as “Link” and add a formula using a concat function, similar to this: concat(‘[your SharePoint document library]’, outputs(‘Create_file’)?[‘body/Path]) This formula adds your document library “https” address such as: https://shanescows.sharepoint.com/sites/DoeHillDrive …to the dynamic content Path from your “Create file” action. You'll simply replace the part of the formula ([your SharePoint document library]) with your own document library. This PdfLink value will be output to Power Apps during the flow run. You can save (and publish if it’s in a solution) and close your flow. Finish the app Return to your app, select the (…) button from the left side rail, and then Power Automate. Make sure that the flow is in your app. Note the schema name under the title, because that’s what you’ll use to call the flow: Next, we add two button controls to our screen, one for initiating the flow, and the other for using the link that returns from the flow. We’ll name one PDF and the other Link. Because we used the Respond to a Power App or flow action in Power Automate, we can harvest that link data by adding a Set function to the button calling the flow in the OnSelect property of the PDF button. Here’s an example: Set( varPdfLink,CreatePDFfromHtmlText.Run(HtmlText1.HtmlText).pdflink); With the link saved to the global variable called varPdfLink, you can now use that with a Launch function in Power Apps that opens the new PDF document in another browser tab. You can add this code to the OnSelect property of your Link button. Launch(varPdfLink) If you run your app, you will be able to use any JPEG and PNG images in your PDF document. You can continue to add HTML code to your HtmlText control to add data to your PDF, but now you understand how to add different image types to the PDF. Here’s how ours looks: Please let us know what you think! For more on this topic, don't forget to check out Shane's video on creating a PDF: Create a PDF from SharePoint Data using Power Apps and Power Automate flow for free

Recently, a change in Microsoft Power Apps affected a common method for enabling file uploads. The attachment control, which users typically copied from a form into a standalone app, no longer functions correctly when used outside the form context. This disruption has affected many makers who relied on that approach since its emergence in 2019. If you've encountered this issue, you're not alone. Fortunately, there's a workaround that helps make it easier to keep file upload functionality in your app—without waiting for a product fix. Shane has documented this in his video: Power Apps Bug & Fix: Attachment Control. What Changed Previously, the process involved: Connecting your app to a SharePoint list. Inserting a Form  control connected to that list. Adding the Attachments  field to the form. Copying the Attachment  control from the form and pasting it elsewhere in your app. Now, when you try to copy and paste that control—even within the same form—it no longer functions properly. The paperclip icon that triggers the file picker disappears, and the control becomes unusable. The Workaround: Drag, Don’t Copy Here’s how to restore file upload functionality: Add a Form to your screen and connect it to a SharePoint list (any list with attachments enabled). Edit the fields in the form to include the Attachments  control. Instead of copying the control, click and drag the entire data card that contains the attachment control outside the form . You’ll see some formula errors. Clean those up by: Removing or correcting the Items property. Setting DisplayMode to Edit. Optionally adjusting styling (e.g., Color to Color.Black ). Once it works, delete the form. The dragged control will remain functional. Why This Works Dragging preserves internal bindings that are lost during copy-paste. This technique isn't documented, and Microsoft hasn't officially acknowledged it as supported behavior. However, it allows your app to continue supporting file uploads until an official fix is released. Known Bug Reference Microsoft has documented this issue as Bug 5096864 , noting that the control "is not designed to work outside of a form." This workaround sidesteps that limitation until the functionality is restored or officially restructured. Final Thoughts If you're building or maintaining apps that rely on file uploads, this drag-and-drop method  offers a workable path forward. We'll share this workaround with Microsoft to help drive resolution. In the meantime, you can keep your apps running smoothly using this approach. For a visual walkthrough, check out the linked video tutorial .

If you've ever felt a bit overwhelmed by the Combo Box control in Power Apps, you're definitely not alone. It's one of the most powerful (and sometimes puzzling) components out there. But don't worry, in this guide, we’re diving into the modern Combo Box, and by the end, you’ll have a solid grip on how to make it work for you. Now if you are more of a visual learner than a reader, there is a full-length video Deep Dive for the Modern Power Apps Combo Box . Me I prefer seeing that reading, so hopefully the video also helps you. Getting Started: Enabling the Modern Combo Box Before you can use the modern Combo Box, you need to turn on the feature in Power Apps: Go to Settings  > Updates  > Modern Controls and Themes  > Toggle ON Insert a Combo Box from Insert  > Input  > Combo Box Populating the Combo Box By default, the Combo Box comes with sample items (Item 1, 2, 3), but that's not what we want. Connect it to a real data source like a SharePoint list, Dataverse table, or SQL. In the video, a list called "Mega" with 10,000+ items is used. One key limitation: the Combo Box only loads the first 800 items . That might sound like a lot, but if your list is bigger, you’ll need to filter or search more effectively. Filtering Items To narrow down the results, you can use the Filter() function. For example: Filter(Mega, AnimalType = "Cow") This helps make large data sources manageable within the 800-item cap. Search Functionality Modern Combo Boxes only search the first 800 items. For a more robust, traditional search, use the Search() function like this: Search(Mega, Self.SearchText, "Title") This makes your Combo Box smarter, especially with large data sets, but keep in mind delegation warnings. Default Selected Items Setting default values can be tricky. The DefaultSelectedItems property expects either a record or a table. To default to a specific item: LookUp(Mega, Title = "Item Title 22") Or use a custom JSON record, but be careful it must be an exact Record match: {Title: "Item Title 22"} If you are struggling with setting the DefaultSelectedItems use this video Power Apps Combo Box DefaultSelectedItems . The video is old but the content has not changed. Multiple Selections Turn on Allow Multiple Selections  to enable checkboxes in the Combo Box. This makes it easy for users to select more than one value. To pull out selected data, use: Concat(ComboBox1.SelectedItems, Title, ", ") This gives you a nice, comma-separated string of all selected titles. Working with People Search Want to select users from Office 365? Add the Office365Users  connector, then set the Combo Box items like this: Office365Users.SearchUserV2({searchTerm: Self.SearchText}).value Use DisplayName for the field shown in the Combo Box, and pull email addresses using: Concat(ComboBox2.SelectedItems, Mail, ";") Bonus: Rounded Corners and Styling Finally, a small but delightful update, modern controls now support border radius ! That means rounded corners are just a click away. Style away to match your app’s vibe. Wrapping Up The modern Combo Box in Power Apps brings a lot of new features and a bit of a learning curve. But once you get the hang of filtering, searching, and managing selected items, it becomes a flexible and user-friendly control. Don’t forget to explore delegation limits and always test with your actual data. Got questions or need help? Hit us up with the Contact button and tell us how we can help.

If you're building custom forms in Power Apps and want a cleaner, more flexible input experience, you can take advantage of the Modern Text Input control. It's designed to be simpler, more accessible, and more in line with current design standards. While there are some great features to try, there are some buggy tradeoffs that make us not quite ready to completely give up the Classic Text Input. This post breaks down what matters most—especially for developers skipping the Form control and building a custom form. We'll look at some of the properties that have changed, what the new ones do, and how to handle validation. All in less than 5 minutes. Classic vs. Modern Property Mapping Here's a quick table to highlight what's changed: Modern Property Classic Equivalent Notes Value Default Holds a default input value of "". No need to replace "Text input". Placeholder HintText Shows hint text when empty. Mode Mode SingleLine or MultiLine only (no Password--see Type). Type (None) New. Choose "Text", "Password", or "Search"--see Type below. TriggerOutput DelayOutput New. More flexible—see TriggerOutput below. Required (None) New. Marks the input as required. ValidationState (Manual styling) New. Set to "Error" to show a red border. Note: Values like Type and Align properties are set using text strings (e.g. "Password", "Center")—not Enum syntax like Align.Center. Type property This property gives the text input a specific role: "Text" – Default. Accepts any text. "Password" – Masks input with dots. Shows a selectable view input toggle. "Search" – Meant for search bars. Currently, there's no difference from a "Text" type. (However, it may show a search icon or clear button in the future.) If you're asking for login info or PINs, use Type = "Password". Otherwise, stick with "Text" or "Search". TriggerOutput property This one's important if you're doing logic as you type. It controls when OnChange fires and when the control's Value updates: "FocusOut" – Default. Fires when the user leaves the field. "Delayed" – About 500ms after typing stops. "WhileTyping" – Updates as the user types, but throttled. "KeyPress" – Fires on every keystroke (use with caution). Pro tip: Use "WhileTyping" if you're building responsive custom forms. It's smoother than "KeyPress" and doesn’t trigger on every character. If you're tabbing through inputs, use the "FocusOut". Required and ValidationState These two make field validation easier: Required = true – Tags the control as required (mostly informational unless you're using forms). ValidationState = "Error" – Turns the border red. You control this manually. Here’s a quick example you can include in OnChange or OnSelect of a control: If(IsBlank(TextInputName.Value) UpdateContext({varNameError: true}), UpdateContext({varNameError: false}) ) Then bind the property: ValidationState = If(varNameError, "Error", "None") Boom—built-in red border. Bonus Tip: Use the Number Input control for Numbers If you're asking for a number, don’t use a text input. The new Number Input control: Opens the right keyboard on mobile Has increment/decrement buttons (with a customizable Step) Enforces numeric input by default It’s mostly better all around. Why We're Not Ready to Give Up the Classic Text Input While the Modern Text Input is sleek and evolving quickly, it’s not quite feature-complete yet. Here are a few frustrations: There is no "Clear button" (or "Enable spell check") option. The AcceptsFocus property isn’t available, so using SetFocus() can get wonky, especially when paired with TriggerOutput = "WhileTyping". Customizing tab navigation isn't an option. The FontSize property (Size in the Classic Text Input) is too small when you first insert the control, prompting you to adjust it. The OnSelect property is missing, so if you need to do something when a user taps the field, you’ll need a workaround. Until these gaps are closed, the Classic Text Input still earns its spot in certain custom form scenarios. Wrap-Up As with other Modern controls, the Modern Text Input shows true promise, but it isn't quite what we're expecting, yet. They're stylish and clean and have a growing range of options. They can enhance the look and feel of your app, but some things they still can't do. There's still a place in our toolbox for the Classic Text Input.

Ready to have your mind blown? That may be a little much, but we are pretty excited for this and think you will be as well. Let’s start with a quick look at how we used to add the Attachment control. Previously, adding the Attachment control involved multiple steps, such as adding a data source, inserting an Edit form, adding the Attachment field, and then manually copying the control outside the form to configure it. That worked for years, still does, and there’s nothing wrong with that approach. Maybe a little excessive on the steps, but hey, it works. But what if I told you there was an easier way to add the Attachment control (or any other control for that matter) in your Power Apps. Odds are if you’re reading this, you are at least somewhat interested ha. You can do this with any existing app or start with a blank app, it’s up to you.  For our example we will be using a blank app to keep things simple. From the Power Apps editor, click the Ellipses at the top and select Settings . On the Settings window, click Support . Make note of the Authoring version, it’s probably 3.25061.7 . We need to change that. Below Authoring version, click Edit . Then, under Authoring version, click the drop-down and select 3.25063.5 . (Your version may be different, but you just want to select the newest version.) Once selected, click Reload + apply version . Power Apps is then going to reload your app and reopen. It’s always a good idea to double-check that your changes were saved and your Authoring version was updated. So, take a moment to confirm your Authoring version now shows as 3.25063.5 or again the version you selected. It’s also important to note that, as a rule of thumb, we don’t recommend doing this in any other cases, as it can get people in trouble. BUT if you need the attachment control working again, you will need to update the Authoring version. And hey, Shane said it’s ok, so it must be alright 😊 Now that the version is updated, you can simply copy and paste the YAML code for the attachment control right into your app. If you’re thinking to yourself, What is YAML code? Let me assure you, it’s fine, you are not alone either 😊. We aren’t even going to get into it, just know that code is what allows you to paste these controls into your apps. Let’s check out how it works. So, from my text editor, you can see the YAML code and properties for the Attachment control. I’ve also included the YAML code below so you can copy and paste it into your app. - Attachment1: Control: Attachments Properties: BorderColor: =Color.Purple BorderThickness: =5 Fill: =RGBA(169,169,169,.5) Height: =268 MaxAttachments: =1 Size: =18 Width: =402 X: =60 Y: =111 All I have to do is copy the code , go into Power Apps, and paste it . Boom! You will see the attachment control is now there and configured with the properties specified in the code. Again, this will work with any of your controls. If you want to get the YAML code for a control, you can add it to your app, right-click on the control, and select View code. If you want to watch the video where Shane walks through these steps, check out the video below.   Whether you are new to Power Apps or an experienced builder, everyone runs into roadblocks. If it happens, just know we are here to help however we can. Just click here , send us a message, and we will be in touch soon.

This blog post is about a reliable technique to capture attachments from Forms and add them to a SharePoint list by using Microsoft Power Automate. We very often use Power Apps as a tool to capture SharePoint data including attachments, but you can also use Microsoft Forms and Power Automate to do it. In the process of figuring this technique out, I did a lot of things that caused the flow to fail. This technique will lead to success. What to know before you try it Why use Microsoft Forms? Microsoft Forms is a tool allowing you to capture data and files in a mobile or desktop experience. To take full advantage of the file upload capability of Microsoft Forms this technique can only be used within your organization. When you use a custom form from Microsoft Forms to allow attachments, Forms stores the attachment files in the form author's OneDrive. So that's where Power Automate must go to retrieve them. The OneDrive for business connection of the person who created the form absolutely must be part of the flow or you won't be able to grab these attachment files. The other "BLL" (big lesson learned) is that using the 'Get file content using path' is nearly impossible to invoke when someone has a complex field name in the form, such as "1 Upload image relative to Performance complaint" (vs. a basic name like "Attachments"). We're talking some really strange encoding for the file path, and given Power Automate's finicky file path translator, you are in for a rough experience if you try to use this action with a hand-crafted file path. Recommendation, always use a 'Get file metadata' action using the ID from a 'Parse JSON' action to discern the exact path...and I suppose you could use that to get the file content as well, but, in this proven solution I use the "Path" value from the 'Get file metadata' action. Works like a charm! Flow Steps 1. Use the 'Get response details' action in your flow after a 'When a new response is submitted' flow trigger. Naturally, this step allows you to look at the action's outputs when looking at the Run history. You'll be able to discern which values are for your attachments, since the output only includes alpha-numeric strings. Your attachment will have a string of JSON to the right of the colon. See the image of the Outputs below: Outputs of the 'Get response details' 2. Use SharePoint 'Create item' action to create an entry for the new item related to the form fields (or a filtered 'Get items' to get the item you need to update). 3. Use a 'Compose' action invoking the json() formula on your attachment field: json() You can look up your field (represented in the code above as between the < and >) which may simply be called "Attachments" (or another more challenging name), and when you put that field into the json() formula, the alpha-numeric value should match the attachments field from the outputs of your 'Get response details'. Compose inputs as a json formula 4. Add a 'Condition' action to check that the Outputs from the 'Compose' action are "not equal to" null, so that you don't have an error in the flow when there is no attachment. (Use the formula value for null.) Condition: is not equal to null 5. In the "True" side of the condition, use a 'Parse JSON' step with 'Body' from the compose action as the Content, and the Schema as: { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "link": { "type": "string" }, "id": { "type": "string" }, "type": {}, "size": { "type": "integer" }, "referenceId": { "type": "string" }, "driveId": { "type": "string" }, "status": { "type": "integer" }, "uploadSessionUrl": {} }, "required": [ "name", "link", "id", "type", "size", "referenceId", "driveId", "status", "uploadSessionUrl" ] } } 6. Add a OneDrive 'Get file metadata' with the file value of 'Body id' (Power Automate will invoke an 'Apply to each' or 'For each' loop because of the array presented from the 'Parse JSON' action). IMPORTANT: ensure that before testing the flow that the person who created the form adds their connection to the OneDrive actions. If you do not do this, your flow will fail because it lacks permission to go into the OneDrive folder location to grab the attachment. 7. Use a 'Get file content using path' (OneDrive) with the Path value from the 'Get file metadata action' to capture the file content. 8. Still in the loop, add an 'Add attachment' (SharePoint) action. Id is from the 'Create item' (SharePoint), File Name is from the Parse JSON action, and File Content is from the 'Get file metadata' action. Add attachment settings Impossible? Never. Please let us know what you think about this technique!

Barcode scanning in Power Apps might just be one of the most underused features that delivers huge value with very little setup. Whether you’re tracking assets, managing inventory, or just trying to avoid user typos, Power Apps barcode scanning makes data entry faster and more reliable. And the best part? It does not require any fancy hardware. In this post, you’re going to learn how to build barcode scanning experiences for both mobile and desktop users. They are totally different since with a PC you have to use a USB Scanner. You’ll see how to connect them to SharePoint or Dataverse for lookups, and even how to integrate third-party APIs for things like product information. Since scanning barcodes is much more of a visual exercise, here is the full length YouTube video on Barcode Scanning in Power Apps . Why Use Barcode Scanning in Power Apps? Typing item IDs or serial numbers by hand? That’s just asking for mistakes. Scanning barcodes keeps your data clean and makes users faster. Common scenarios include: Asset management:  Tag office equipment or tools with barcodes to track location, quantity, and maintenance. Job tracking:  Have drivers or field techs scan a location barcode when they arrive or depart. Inventory or product lookup:  Scan UPC codes to show descriptions, pricing, or vendor info. Document management:  Use barcodes to tie physical paperwork to digital records in Dataverse or SharePoint. The Power Apps Barcode Scanning experience on mobile. Example 1: Mobile Barcode Scanning Let’s start with the built-in Power Apps barcode scanner that works on iOS and Android. Create a new Canvas App (phone layout). Go to Insert > Media > Barcode reader  and drop the control on your screen. Change the button text to “Scan.” When you tap the scan button on a phone, Power Apps uses the device’s native camera to detect barcodes. This control isn’t a Microsoft-built scanner; it’s using the same system the iPhone or Android uses. So, on a PC, it won’t work, but more on that later. You can check out the available barcode types by selecting the control and looking at its BarcodeType  property. Leave it on Auto  unless you know you need a specific format like Code128, QR code, or UPC. Understanding Scan Modes Power Apps offers a few ways to control the scanning behavior: Automatically Scan:  As soon as the camera detects a barcode, it instantly captures it (great for fast workflows). Select to Scan:  The user must confirm the scan with a checkmark before it’s processed. Scan Multiple:  Lets users capture several barcodes in one session. Scan Inline:  This one exists, but in my experience… it doesn’t work. You’ll see it listed, but I’ve never gotten it to actually do anything useful. Working with the Scanned Data When you scan something, the results come back as a table  of barcodes. Even if there’s only one, you still have to handle it as a table. For a single scan, use: First(BarcodeReader1.Barcodes).Value That returns the actual barcode number (the “value” field).If you also want the barcode type, use: First(BarcodeReader1.Barcodes).Type For testing, Power Apps provides a fake barcode value like 1231412  when you run it in the studio. That’s handy for building your logic without switching to your phone every time. If you’re doing multiple scans, you can load the entire table into a collection  and display it in a Gallery . For example: Items = BarcodeReader1.Barcodes That’ll show all your scanned codes in a list. Example 2: Launch a URL from a QR Code QR codes are just as easy. You can use the same control, but this time, trigger an action after scanning. In the OnScan  property of the barcode reader, use: Launch(Last(Self.Barcodes).Value) If the scanned code contains a URL, Power Apps will open it automatically in a new browser window. You could just as easily use OnScan to look up data in Dataverse, patch a record, or set a variable. The Power Apps Mobile Barcode Scanner viewing a QR code. Example 3: Barcode Scanning on a Desktop PC What about users who aren’t on mobile? Good news! You can still scan barcodes on a PC using a USB barcode scanner. The secret: your USB scanner acts like a keyboard . Every time you scan, it “types” the barcode value into whatever input box has focus. Here’s how to handle that in Power Apps: Add a Text input  control. In its OnChange  property, capture the scanned value: Set(varScan, Self.Text); Reset(Self) Display the result in a label: Text = varScan Now when you scan with your USB scanner, the barcode will appear in the text input, trigger the OnChange formula, and clear itself ready for the next scan. You could easily adapt this to add each scan to a collection for batch processing or logging. We see this a lot in manufacturing or assembly type scenarios. Tips and Tricks Barcode and QR stickers are super cheap. You can get custom ones with your logo and color scheme from Amazon for about $12 for a pack of 100. Power Apps can recognize most standard barcode types (Code128, QR, UPC, etc.). You can even generate your own barcodes using online tools or ask Copilot or ChatGPT to create an image for you. If you’re using SharePoint or Dataverse for lookups, match the barcode value  to a column in your table or list for an instant record lookup. Learn how: Power Apps Asset Management Video . Wrapping It Up Barcode scanning is one of those Power Apps features that delivers big value with minimal effort. Whether you’re tracking assets, scanning products, or just trying to make data entry painless, it’s worth adding to your toolkit. And the best part? You can build it today — no plugins, no custom code, just Power Apps. If you’d like help building your own barcode or QR-based apps, the PowerApps911 team builds these kinds of solutions for customers around the world every week. We’d love to help you bring your idea to life. Just hit that Contact button at the top of the page.

If you’ve ever wished you could build a Power App just by describing what you want… well, now you can. Microsoft just introduced a brand-new way to build apps called Vibe Coding, available today at Vibe.PowerApps.com . This new experience blends natural language, Power Apps AI, Dataverse, and automatically generated React code to help you build full apps from scratch using nothing but your words. In this blog post, you are going to see exactly how Vibe Coding works, what you need to use it, and why it is absolutely not ready for production yet. But if you want to explore the future of Power Apps development, this new experience is going to give you a whole new way of thinking about app building. And a reminder, if you prefer the hands-on approach, check out my full video walk through on YouTube. New at Ignite: A new way to Power App with Vibe Coding What Is Power Apps Vibe? Vibe is a brand-new app type inside Power Apps. It joins the family alongside Canvas apps and Model-Driven apps, but it works very differently. Instead of starting with screens, data sources, or UI components, you start by simply describing what you want. You type in your own words a description of the app you want to build, and Power Apps AI generates: User requirements A full plan A Dataverse data model React-based app code A working version of your app you can interact with Think of it as building an app by brainstorming out loud. If you say, “ I need an incident reporting tool where users can log incidents, add witnesses, track severity, and see a dashboard... ” Vibe creates the tables, relationships, and screens automatically. Enhancing Your Prompt With AI Before your prompt is sent off to create the app, there is an “Enhance Prompt” option. This uses Power Apps AI to rewrite your description, tighten up your requirements, suggest additional details, and give you a sense of what a more complete request looks like. This is super helpful because it teaches you how detailed you should be when writing your prompts. Over time, you’ll get better at giving AI the right level of detail to generate stronger apps. Watching Vibe Build the App Once you click Go, Vibe shifts into Plan Designer mode. You actually watch it run through user requirements, data modeling, and then the app build phase. Instead of the step-by-step experience you might have seen in Canvas plan building, Vibe runs everything in one automated pass. Behind the scenes you’ll see it writing real React code. You never have to touch that code directly, but you can open it and peek if you're curious. I have never written React code, I am not a pro developer, and none of that matters. Like the Matrix, just don't look at the code and you don't even have to think about it being there. 🤣 Editing and Iterating With Vibe Coding This is the magic part. After your app is created, you can run it, test it, and if you see something wrong, simply tell Vibe what to fix. You don’t need to hunt down formulas or rewrite UI logic. You type plain language instructions like: “When viewing the list of incidents, I want to click an incident and see the full details including witness statements.” Hit Enter, and Vibe rewrites the affected code and updates the app. You can also use inline edit mode where you click on a specific UI element and leave AI-guided comments tied to that exact part of the app. This gives Vibe the perfect context so your fixes are more accurate. Understanding the Data Model Every Vibe app uses Dataverse today. When it builds your app, it also creates Dataverse tables in draft mode. These aren’t real yet, and nothing is saved until you publish. You can: View the tables Edit column names Remove tables Add existing Dataverse tables Add entirely new tables Later, when you publish, Vibe creates the real tables and connects your app to them. Publishing Your Vibe App Once you’re happy with your app, you can publish it. Publishing: Creates the actual Dataverse tables Pushes the React app into the Power Apps framework Finalizes the solution so the data becomes real After publishing you can share the app like any other Power App. Requirements To Use Power Apps Vibe Before you jump in, there are some important requirements from the video: You must run Vibe in a non-default Power Platform environment You must be using a US region environment You must be signed in from a US language browser You must have the System Customizer role (or higher) Vibe currently only publishes to Dataverse This is early preview, so expect slower load times and rough edges If you load Vibe.PowerApps.com and see an access error, it probably just means you are in the default environment. Switch environments using the prompt at the bottom of the screen. A Very Important Warning: Vibe Is Super Early Preview This is the part that every reader needs to hear clearly. Vibe coding is extremely early preview. You should not use this to build production apps right now. The generated apps are very cool for learning and experimentation, but they are not designed to replace your Canvas apps, Model-Driven apps, or existing Power Apps architecture. For example: Only Dataverse works today No support for multiple data sources No offline support No barcode readers or rich device features No custom controls No direct code edits No workflows or agents generated automatically Performance and stability will change as preview evolves Canvas apps and Model-Driven apps aren’t going anywhere. You still need their maturity, their flexibility, and their deep ecosystem integrations. Vibe simply adds another flavor of app building that will get more powerful over time. Want Help Learning More About AI in the Power Platform? If you’re trying to make sense of Power Apps AI, Vibe Coding, Copilot Studio, and all the new Ignite announcements, you’ll find live classes, on-demand training, and Power Platform coaching over at Training.PowerApps911.com . We also help companies plan, build, and deploy real AI solutions across the entire Power Platform. Agents, Apps, and Workflows! So reach out if your team wants to become a true AI-enabled organization.

Error handling in Power Apps is one of those topics everyone knows they should care about… but very few people actually implement well. Most apps rely on a red error bar, maybe a Notify(), and then hope the user doesn’t notice when something quietly fails like below. BTW - How is it that users manage to not see that big pink bar? It happens so often and breaks my brain, Power Apps errors are often not secrets. Anyway, the built in Power Apps error handling works right up until your app is in production, users are clicking fast, data isn’t perfect, permissions change, or a flow decides to fail on a random Tuesday afternoon. I don't know why it is always Tuesday, but it is. If you are building Power Apps that real people depend on, you need a real error handling strategy. Not something fancy. Not something over-engineered. Just something... that works. This post walks you through a practical approach to Power Apps error handling, by showing you three tools every app builder should know: IfError to catch errors you expect OnError to catch errors you didn’t expect And how to add logging so you don’t lose errors if they happen Why error handling in Power Apps matters Power Apps will happily let your app continue running even when something fails. A Patch can fail. A flow can fail. A connector call can fail. Sometimes you get a red bar. Sometimes you get nothing. Either way, your app often keeps going like everything is fine. One of the biggest mistakes I see here, is when you Patch and Navigate. If you just separate the two functions with a ; then Power Apps will take them to the next screen no matter how loudly Patch screams. Below is the most common way we see it written OnSelect for a button. That’s the dangerous part. Without error handling: Users don’t know their action failed Data doesn’t save the way you think it did You have no idea something broke until someone emails you Reproducing bugs becomes guesswork Good error handling isn’t about preventing errors. It’s about detecting them, responding appropriately, and giving yourself enough information to fix them later. (But of course, writing formulas without errors is always a good idea also) Catching expected errors with IfError The first layer of Power Apps error handling should always be IfError. IfError is designed for situations where you already know something might fail. Common examples include: Patch operations Collect or Remove calls Submitting data to SharePoint or Dataverse Calling a Power Automate flow Writing to a data source with required columns or permissions IfError does not fix anything, it simply gives you control when something goes wrong. Check out the example below: This tries a Patch. If the Patch fails then it triggers a variable that makes a giant error screen shows up and it uses a User Defined Function to save the error details to your error logging table. If the Patch works, it navigates to the next screen as expected. The key idea is this: if you can predict that an operation might fail, wrap it in IfError and decide what should happen next. That might mean: Showing a friendly message to the user Logging the error Preventing the user from navigating away Retrying the operation What you should not do is let the app fail silently and hope the red bar is enough. You want to create a Handled Error . This means that instead of letting Power Apps just fail and deal with it, you say if this error happens, then handle it like so. Check out the video on the Power FX IfError function to see in detail how to use the function. Catching unexpected errors with OnError Even if you are disciplined about using IfError, you will miss things and end up with UnHandled Errors . Large apps have lots of formulas, screens, controls, and connectors. Some errors only show up at runtime. Others happen before your variables finish loading. That’s where the Power Apps property App.OnError comes in. OnError is global. It fires when an unhandled error occurs. Think of it as a safety net, not a replacement for IfError. This is especially useful for things like: Runtime formula errors Connector timing issues Noisy errors from connectors like Office 365 profile calls that briefly fail and then succeed A great real-world example is Office 365 user profile calls. Many apps briefly throw an error while profile data is loading, even though everything works a moment later. UGH. Wrapping every single call in IfError is messy and repetitive. Using OnError gives you a single place to suppress or handle that noise intelligently. The important rule here is intent. OnError is not for ignoring real failures. It is for catching things you didn’t plan for or filtering out errors that are not actionable. Important: OnError is not a function, it is a property of the App object that runs when an Error occurs. As seen above, what you do inside of there is up to you. You can do everything from reinvent the error message screen, to logging, or even suppressing. The world is your oyster. To see OnError in action check out this video H andling the unexpected errors in Power Apps with OnError . Do you have errors in your Power Apps and need a helping hand? Hit the Contact button and let us know. We are happy to give you a nudge, hop on a screen share, or do the whole project. Understanding Errors and FirstError Power Apps gives you two related tools for viewing error details that often get mixed up: Errors() and FirstError. Errors() is tied to a specific data source. It returns a table of errors from the most recent operation against that source. This is useful when you know exactly what failed and want detailed information. Use it with IfError. FirstError is global. It does not require a data source. It works with App.OnError and in situations where you don’t know what just failed, only that something did. Understanding this distinction alone clears up a lot of confusion around Power Apps error handling. Each is shown in the related video for IfError or OnError. FirstError has the most details but sadly doesn't work with IfError. Logging errors so you don’t lose them Catching errors is only half the job. If you never see them again, you’re still guessing. This is where logging comes in. A simple SharePoint list is more than enough for most apps. You don’t need a monitoring platform. You don’t need dashboards on day one. You just need a place to write errors down. At a minimum, logging should capture: What app the error came from What screen it happened on What control or action triggered it The error message itself SharePoint already tracks who created the record and when, so you get user and timestamp data for free. Once you are logging errors, notifications become optional. An email when something critical fails can be helpful, but the real value is having a history you can review later. If you want to get real fancy, then check this out. An example of using a User Defined Function (UDF) for the error logging: By using a UDF you make the error handling easy to reuse throughout the app. Also, in this example, it has logic to suppress multiple error messages. Not saying suppression is a good idea, but sometimes it is a necessary evil until you get things sorted. In the third video of the series, I show how to log errors to SharePoint and optionally send an Outlook email, using a reusable User Defined Function so the same logic works from IfError, OnError, or both. Video: Power Apps Error Logging and Notifications Why this layered approach works The mistake most people make is looking for a single “error handling solution” in Power Apps. There isn’t one. Instead, think in layers: IfError for expected failures OnError for unexpected or noisy failures Logging so nothing disappears Each layer does one job. Together, they make your apps more reliable, easier to debug, and far less stressful to support. Final thoughts Power Apps error handling doesn’t have to be complicated, but it does have to be intentional. If you only rely on the red error bar, your app is lying to you. If you never log errors, you are flying blind. The good news is that a small amount of structure goes a long way. Once you start thinking about failure paths instead of just success paths, the quality of your apps improves fast. If you want to see these patterns implemented step by step, there are three companion videos that walk through use the links to the specific videos above, or you can use the whole Power Apps Error Handling playlist . That’s how you stop guessing, stop losing errors, and start building Power Apps that behave like real production apps.

If you are using Microsoft Dynamics 365 Business Central , you already have a powerful ERP that sits inside the Microsoft ecosystem.  That is both a blessing and a trap.  Because Business Central integrates so well with Microsoft tools, it is tempting to customize it heavily. Before long, finance teams end up managing workflows, forms, approvals, and reporting inside the ERP that were never meant to live there.  This is where the Microsoft Power Platform comes in. Not to replace Business Central or turn it into a low-code playground, but to extend it in the right places.  What you’ll learn in this article: When to extend Business Central instead of customizing it How Power Apps improves processes for non-ERP users Why Power Automate is better for complex approvals How Power BI and Microsoft Fabric improve ERP reporting How to reduce upgrade risk while improving visibility   The Guiding Principle  Business Central should remain the system of record for financials and operations.  The Power Platform should handle:  User interaction  Workflow and approvals  Automation across systems  Analytics and visibility  When each tool stays in its lane, Business Central stays stable and scalable.    Use Power Apps for Processes That Involve Non-ERP Users  One of the most common mistakes we see is forcing everyone into Business Central.  Not everyone needs ERP access. In fact, many people should not have it.   Using Power Apps , teams build lightweight apps for things like:  Purchase requests  Vendor intake  Expense submissions  Project or job setup requests  Customer-facing forms  These apps collect clean, structured data and apply business rules before anything touches Business Central.  Finance teams stop fixing inputs. Business Central stays cleaner. Users get a simpler experience that does not require ERP training.    Handle Approvals With Power Automate, Not Custom Logic in Business Central  Business Central has approval capabilities, but they can become complex quickly when approval paths vary by amount, department, or role.  With Power Automate , approvals can be handled outside the ERP while still integrating cleanly with it.  Common scenarios include:  Multi-level approvals based on dollar thresholds  Conditional routing based on department or job  Escalations when approvals stall  Full audit trails with timestamps and comments  The result is stronger controls without cluttering Business Central with workflow logic that is hard to maintain.    Automate Integrations Instead of Building Everything Inside Business Central  Business Central often sits at the center of many systems.  CRM, time tracking, payroll, support platforms, and project tools all need to interact with it.  Rather than embedding custom integrations directly into Business Central, Power Automate is often the better integration layer.  Examples we see frequently:  Syncing customers and jobs from CRM  Bringing approved time and expenses into Business Central  Pushing status updates back to teams  Coordinating data flow across multiple systems  This approach keeps Business Central focused on core ERP functions and reduces upgrade and maintenance risk.    Use Power BI to Make Business Central Data Easier to Consume  Business Central has reporting, but most leaders want answers, not ERP screens.  With Power BI , Business Central data can be turned into dashboards that show:  Budget versus actuals  Job or project profitability  Revenue and margin trends  Cash flow visibility  Security can be applied so users only see what they should. Finance teams spend less time exporting data and more time analyzing it.    Where Microsoft Fabric Fits In  As reporting and data needs grow, some organizations hit the limits of direct ERP reporting.  This is where Microsoft Fabric becomes a strong addition.  Fabric allows Business Central data to be combined with data from other systems in a centralized analytics layer.  This is especially valuable when teams want to:  Analyze multi-year history  Combine financial and operational data  Answer cross-system questions about profitability or performance  Standardize reporting across departments  Business Central remains the system of record. Fabric becomes the analytics foundation.    When to Extend Business Central vs Customize It  A good rule of thumb we share with clients is this:  Customize Business Central when the logic is core to accounting or operations. Extend with Power Platform when the logic is about people, process, or visibility.  Examples that belong outside Business Central:  Intake forms  Department-specific workflows  Cross-system approvals  Executive reporting  Examples that belong inside Business Central:  Core posting logic  Financial controls  ERP-native configuration  This balance keeps Business Central maintainable long term.    The Bottom Line  Business Central works best when it is not asked to do everything.  By using the Power Platform and Microsoft Fabric around it, organizations get:  Better user experiences  Cleaner data  Stronger controls  Better insight  Less risk during upgrades  Business Central stays stable. The business stays flexible.    Want Help Extending Business Central the Right Way?  At PowerApps911, we help teams use the Power Platform and Microsoft Fabric to extend Business Central without turning the ERP into a bottleneck.  If you are debating customization, struggling with approvals, or trying to get better insight out of your Business Central data, we can help you map a safer, more scalable approach.  👉 Reach out to talk through your use case or start with a small pilot that actually solves a real problem.