Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. The formula you keep writing over and over. In September of twenty twenty five, Power Apps added something called User Defined functions. You write a formula that works, then you need the same logic somewhere else, so you copy it. Then you need it a third time. And now the same rule lives in three places you're afraid to touch. By the end of this, you'll know what they are, where you write one and the honest limits worth knowing before you lean on them. This is the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. What a user defined function actually is. Let's start with the plain version. Because the phrase user defined function sounds far more intimidating than the idea sitting behind it. A user defined function is a formula you write yourself, you give it a name, and then you call that name wherever you need it. That's the whole idea, and everything else is detail. You already write formulas and power apps probably more than you realize. When you tell a label to show some text or a gallery to filter a list, you're writing a formula. Power apps also ships with hundreds of built in functions, and you've almost certainly used a few already. If text, filter, sum and mismatch are all functions that Microsoft wrote for you in advance, a user defined function is the same kind of thing, except this time you're the one who writes it. Microsoft didn't add this to make PowerApps harder. They added it because the copy and paste habit was showing up in apps everywhere, and it made those apps a chore to fix. A function gives that repeated logic a home and a name you can call. Here's what makes it worth your attention. A normal formula lives inside a single control on a single screen, and it stays there. A user defined function lives in one central spot and can be called from anywhere in the app, on any screen, as many times as you like. You write it once and then you reuse it. And that reuse is the entire point of the feature. The other word worth unpacking is parameter. A parameter is just an input you hand to the function. If your function works out a discount, one parameter might be the price and another might be the type of customer you don't rewrite the function for every customer, you call the same function and pass a different value, and it works out the answer each time. Once a rule has a name, you can also test it on its own without hunting for the screen that happens to use it. That sounds like a small thing until you're staring at an app with twenty screens. There's a reason this idea shows up in almost every programming language ever made. Reuse is how people keep things manageable, and a user defined function is just that idea. Arriving in a tool you can already use. So if you take nothing else from this section, take this. A user defined function is your own reusable formula with a name you feed, it inputs it, hands you back a result, and you use it exactly like the functions that already come with power apps. Why? Copying and pasting formulas breaks down. Before this feature existed, the normal way to reuse logic was to copy it. You'd finish a formula, and when you needed it again, you'd paste it somewhere else. That works perfectly well. While the rule never changes and it falls apart the moment the rule does. Picture a small app for tracking requests. A request can be open, in progress or closed, and you want each one to show in a certain color. So you build a formula that turns the status into a color and you put it on the gallery. Then you add a second screen with its own list. So you paste the same formula there too. Then someone asks for a detailed view, and now the same logic is sitting in three places. Two weeks later, your manager decides closed requests should be gray instead of green. You open the app, you find all three spots, you change them, and you hope you didn't miss one. If you did miss one, you now have an app that shows the same status in two different colors, and it looks like a bug. Even though every single formula is doing exactly what it was told. That's the real cost of copy and paste. And it isn't typing time because typing is quick. The cost is that your rule now has several versions, and the only thing keeping them in sync is your memory. Every change turns into a small hunt. None of this is about being clever. It's about the simple fact that people forget things. And a rule spread across several screens relies on you remembering every single one of them. A user defined function flips that around. The logic lives in one place. You give it a name, and every screen calls that name instead of holding its own copy. When the rule changes, you change it once and the whole app follows along. Microsoft's own description of the feature makes this point directly. Pulling shared logic into a single function with parameters reduces duplication and stops the logic from drifting out of sync. The result is an app that's easier to read, easier to test, and far less scary to change. When you write a function and how the syntax reads. Now for the practical part, because none of this matters until you know where to type it. Open your app in PowerApps studio and look at the left side where the tree of screens and controls lives. At the very top of that tree is the app object, which represents the whole app. Rather than one screen, select it and then in the property, drop down next to the formula bar. Choose the one called formulas. That's where user defined functions live, and anything you write there becomes available everywhere in the app. The syntax looks like a lot the first time you see it. So let's read one out loud like a sentence instead of staring at symbols. Here's a small one that converts a temperature from Fahrenheit to Celsius. It starts with the name you're giving the function, then an open bracket, then the input it expects and what kind of value that input is. After that comes a close bracket, a colon, the kind of value it sends back an equal sign. And finally the formula itself. Spoken out loud, it says something like this. Take a number called F and give back a number worked out as f minus thirty two divided by one point eight. Because the formulas box holds a list of definitions, each one finishes with a semicolon. That's the whole shape of it. And there are only four pieces to keep straight. First comes the name you invent. Second come the inputs in brackets and each input gets a type like a number or some text. The name matters more than you'd expect, and it's the one part of the syntax that's entirely up to you. Call it something that says what it does like discount, total or email check and future. You will thank present. You call it thing one and you'll be guessing in a month. Third comes the type of the result which tells PowerApps what kind of value to expect. Back forth comes the formula after the equal sign. And that formula is ordinary PowerApps formula language the same kind you already write every day. The typing is the part that feels new, and it's worth understanding why it's there. When you say an input is a number, you're telling PowerApps that this function expects a number and not a word or a date. If you later call it with the wrong kind of value, PowerApps can warn you straight away instead of failing in some confusing way. Once the app is running, it's a little extra care up front that saves you a headache later. A small amount of typing now buys you fewer surprises when the app is in someone else's hands. One more thing worth knowing before we move on. Because this function sits at the app level rather than inside a control. You can call it from anywhere. You could put it in a label to test it with a fixed number, or point it at a slider. So the person using the app can move the number around. Same function, two very different uses. And you never wrote the calculation twice. And this is only the kind of function that works out of value. There's another kind that actually does things and it's worth seeing. So hold that thought. A simple example you can picture. Let's make that temperature function do some real work so it stops being abstract. Say you're building a small app for a science class and students need to see both scales at once. You drop a slider on the screen so they can pick a temperature in Fahrenheit. Then you add a label, and in its text you call your function. With the sliders value. The label shows the Celsius number, and as the student drags the slider, the Celsius number moves with it. You didn't write any new logic for that. The function just recalculated the same way a built in function would. Now say you want a second label somewhere else on the screen. Maybe a note that says whether the temperature counts as warm or cold. You don't copy the conversion. You call the same function again, wrap it in a simple if statement and return the word warm or the word cold. One function is now feeding two parts of the app, and the conversion math exists in exactly one place. This is where the idea usually clicks for people because the payoff is small but real. If someone later tells you the conversion should round to one decimal place, you open the function, add the rounding, and both labels update together. No hunting through screens, no second copy, and no chance of the two labels disagreeing with each other. There's a team benefit here too, and it matters the moment more than one person touches the app. When the rule lives in one name place, a colleague can find it, read it, and trust it. Instead of wondering which of the several copies is the real one. And it isn't only about temperature. The same pattern works for a discount rule, a status color, a currency format, or a check that an email address looks right. Take the discount rule as a second example. Say every order gets ten percent off, but loyalty customers get twenty. You could write that decision into every screen that shows a price, or you could write one function that takes the price and the customer type and returns the discounted total. Every screen then calls the same function and shows the same answer. The first time you fix something in one place and watch every screen heal at once, You'll understand why people bother with any of this. Once you've done that a couple of times, something shifts in how you build. You start noticing all the places where you used to copy and paste without thinking, and you want to pull each one into its own little function. That's not busy work for its own sake. It's the difference between an app. You can still change in six months and one you're nervous to open. Functions that do things, not just calculate everything so far has been the calculating kind of function. You hand it a value and it hands one back. There's a second kind and it does something to your app rather than just working out an answer. Think about a button that saves a new sale when someone clicks it, you want to add a row to a list and show a small confirmation message. That's an action, not a calculation, and a user defined function can hold it instead of a plain formula. After the equal sign, you wrap the steps in curly braces and you list them one after another, separated by semicolons. The return type for this kind of function is a special word that means it gives nothing back because the point isn't a value, it's the work it does. Here's the shape of it. In plain words. You name the function, you give it inputs like the customer name and the amount, and you mark it as returning nothing. Then inside curly braces, you write two steps. The first step adds the sale to your list. The second step shows a notification telling the user what just happened. Now any button in the app can call that one function, and the behavior behind it is defined in a single place. Put simply, the calculating kind answers a question, and the acting kind does a job. Keeping those two ideas apart as you build will save you confusion later. That's useful, and it comes with a caution from Microsoft that's worth passing on. In their own announcement, they say that the plane calculating style is always the better choice, and that you should reach for the action style only when you truly have to. The reason is simple enough a function that only calculates is predictable because you can look at the inputs and know the output. A function that changes things while it runs can have effects you didn't plan for, and those effects get harder to trace as an app grows. So reach for the calculating kind first and save the acting kind for the moments where there's no cleaner way. A handful of action functions in an app is usually fine, dozens of them. All changing things behind the scenes is where an app starts to feel unpredictable. Where this fits in Microsoft three hundred sixty five and Azure, It helps to zoom out for a moment and see where this little feature actually sits, because the name PowerApps can feel like it came from nowhere. PowerApps is part of something called the Microsoft Power Platform, which is the family of tools Microsoft gives you for building things without being a full time developer. Alongside PowerApps, you'll find Power Automate for automating tasks, PowerBI for dashboards, and power pages for websites. That whole family lives inside the Microsoft three hundred sixty five world you probably already use for email, files and chat, so these tools aren't a separate universe you have to move into, and they sit right next to the things you already open every morning. When you build an app, the data behind it usually comes from somewhere you already have. It could be a list in SharePoint or a table in Dataverse, which is Microsoft's database service for these apps. Or it might be teams. You're not setting up a server in a basement somewhere. The app and its logic run in Microsoft's Cloud on Azure, the same cloud that powers a huge amount of Microsoft's other services. If you're new to all of this, the useful thing to remember is that you're not learning a separate platform. You're using the same Microsoft world you already log into, just with a builder attached to it. Here's the honest part about scope, though a user defined function lives inside one app, its app level logic, not a cloud service. You go and deploy, and it won't travel to your other apps on its own. If you want to share the same logic across several apps, that's a related but separate idea. Microsoft handles it with components and component libraries, which became generally available in the middle of twenty twenty five. For now, hold on to this a user defined function is a small local tool that lives with your app, and that's exactly what makes it easy to pick up the honest limits. You should know every tool has edges, and knowing them is what separates someone who uses a feature well from someone who gets frustrated by it. So let's walk through the limits of user defined functions. Honestly, the first one we already touched on, a user defined function belongs to one app and stays there. It won't hop over to your other apps by itself. So if you've built five apps that all share the same discount rule, you'll be writing that rule five times once per app until you look into components. The second limit is that a function can't call itself yet. In programming, a function that calls itself is how you handle certain problems that repeat in smaller and smaller pieces, like walking through a folder. tree. PowerApps doesn't support that in user defined functions right now. So if a problem needs that pattern, you'll have to solve it a different way. The third limit is about how picky the types are. Remember that every input and every result has to be labeled with its type, and that care is a good thing. Most of the time, it also means you can't leave an input blank, because in the basic form, all the inputs are required, and there's no such thing as an optional one just yet. And when you start parsing whole records around, the shape has to match what you defined almost exactly, with no extra fields sneaking in. Get that wrong and the function simply won't accept what you gave it. That's the kind of error that's easy to fix once you know the rule. And confusing when you don't. One more practical note the doing kind of function, the one that changes things, is best used sparingly for the reason Microsoft gives. A few are fine, but a whole app built out of functions that change things while they run is much harder to follow, and you'll spend more time chasing side effects than you save. Now for the reassuring part. This isn't experimental anymore. Microsoft moved user defined functions to general availability in September of twenty twenty five, which means the preview switch is gone and the feature is ready for real apps you'd actually put in front of people. So the limits above are worth knowing, but none of them is a reason to wait. If you want to go further, Microsoft's own documentation walks through the syntax and the examples, and it's written plainly enough for a beginner to follow. What to remember and a question for you. So let's pull it together. A user defined function is really just your own formula with a name. You write it once in the app's formulas area. You hand it the inputs it needs, and you call it from anywhere in the app. Instead of copying the same logic into every corner, it keeps your app readable, it makes changes safer, and it has a few honest limits around sharing and repetition that are worth remembering. That's the idea in one line, and the rest is practice. You don't need to be a developer to use one, and you don't need to understand every corner of power apps first. You just need one formula you're tired of repeating. Here's a question for you. Think about the app you're building or the last one you built, and ask yourself where you typed the same formula more than once. That spot is your first user defined function. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.