WEBVTT 1 00:00:00.080 --> 00:00:02.640 You know those times when power apps just hit a wall, 2 00:00:02.799 --> 00:00:06.200 maybe a workflow stumbles, or thattaverse can't quite crunch it. 3 00:00:06.559 --> 00:00:08.439 What if I told you there's a way to break 4 00:00:08.439 --> 00:00:12.720 through with almost unlimited processing power without leaving the Microsoft ecosystem. 5 00:00:12.839 --> 00:00:15.679 Today we're unpacking how Azure functions and power apps can 6 00:00:15.720 --> 00:00:18.239 work together, so your apps are never boxed in by 7 00:00:18.399 --> 00:00:21.879 low code limits. Stick around, because we're not just patching cracks. 8 00:00:21.879 --> 00:00:24.719 We're building a system where every part does what it 9 00:00:24.760 --> 00:00:28.839 does best, securely and at scale. Why fusion what power 10 00:00:28.839 --> 00:00:31.399 apps and Azure functions each bring to the table. If 11 00:00:31.399 --> 00:00:33.600 you've ever found yourself hitting the upper limits of what 12 00:00:33.640 --> 00:00:36.759 power apps can handle, you're not alone. Anyone who's put 13 00:00:36.799 --> 00:00:39.439 together even a modest business app in power apps has 14 00:00:39.520 --> 00:00:43.759 noticed there's a ceiling. You can build forms, automate simple workflows, 15 00:00:43.880 --> 00:00:46.759 drop in a gallery, maybe connect a few lists or 16 00:00:46.759 --> 00:00:49.439 tables in data verse, and for many departments, that's the 17 00:00:49.479 --> 00:00:53.079 magic apps without a developer inside. But run into anything 18 00:00:53.119 --> 00:00:56.119 more demanding and you'll see where things unravel. For instance, 19 00:00:56.119 --> 00:00:58.759 you want to run a calculation using a custom algorithm 20 00:00:58.799 --> 00:01:02.159 built by your analytics team, Power apps isn't designed for 21 00:01:02.240 --> 00:01:04.920 that sort of heavy lifting, try to work around it, 22 00:01:05.159 --> 00:01:08.840 and you're suddenly stuck staring at delegation warnings, capped data 23 00:01:08.840 --> 00:01:12.079 set queries, or screens that crawl when someone tries to 24 00:01:12.120 --> 00:01:15.840 crunch numbers across thousands of records. Things only get more 25 00:01:15.879 --> 00:01:19.359 interesting once you venture outside the Microsoft three six five ecosystem. 26 00:01:19.719 --> 00:01:22.159 Maybe marketing wants to pull in risk scores from a 27 00:01:22.239 --> 00:01:25.920 non Microsoft API, or legal needs to validate data against 28 00:01:25.920 --> 00:01:30.480 an external government service. Power apps left alone just isn't 29 00:01:30.519 --> 00:01:33.680 set up for these leaps out of the box. Connectors 30 00:01:33.760 --> 00:01:35.879 can take you part of the way, but sooner or 31 00:01:35.959 --> 00:01:38.959 later you need something more direct. That's right about when 32 00:01:39.000 --> 00:01:42.200 the suggestion hits why not use as your functions On 33 00:01:42.239 --> 00:01:45.319 the surface as your function sounds like cheating the system, 34 00:01:45.719 --> 00:01:48.680 a way to slip in CEE, sion or JavaScript and 35 00:01:48.719 --> 00:01:52.000 suddenly let your power apps do things Microsoft never planned for. 36 00:01:52.599 --> 00:01:55.120 Need to check inventory in a legacy ERP, No need 37 00:01:55.159 --> 00:01:57.879 to build an entire backend, just have power apps call 38 00:01:57.959 --> 00:02:00.640 a custom function, get back what you need and move on. 39 00:02:01.040 --> 00:02:03.640 The biggest appeal is you don't need to overhaul your 40 00:02:03.640 --> 00:02:06.959 solution as your functions bolt onto your existing app, letting 41 00:02:07.000 --> 00:02:10.680 you layer in power as your requirements evolve. The integration 42 00:02:10.840 --> 00:02:12.879 isn't perfect, but it means you don't need to throw 43 00:02:12.919 --> 00:02:15.080 out weeks of low code work just because you need 44 00:02:15.120 --> 00:02:17.759 a bit of real coding under the hood. Of course, 45 00:02:17.800 --> 00:02:20.800 it's worth asking does this always make sense? Not everyone 46 00:02:20.840 --> 00:02:23.719 buys into the Azure functions hypes. Some architects will tell 47 00:02:23.759 --> 00:02:26.680 you that the second you start peppering Azure functions into 48 00:02:26.719 --> 00:02:29.759 a low code project, you're probably just hiding complexity instead 49 00:02:29.759 --> 00:02:33.639 of managing it. Every new function is another end point 50 00:02:33.719 --> 00:02:38.080 to secure, another piece to document, and another spot where 51 00:02:38.080 --> 00:02:40.840 something can break. There are plenty in the power platform 52 00:02:40.840 --> 00:02:43.680 community who will point out cases where adding functions only 53 00:02:43.759 --> 00:02:47.159 made support harder, not easier. But then talk to anyone 54 00:02:47.199 --> 00:02:49.960 who's tried scaling a business critical power app and they'll 55 00:02:49.960 --> 00:02:52.199 tell you, frankly, you don't have a choice. If the 56 00:02:52.240 --> 00:02:56.400 CFO is waiting for dashboards that need live calculations from 57 00:02:56.479 --> 00:02:59.280 half a million records, you won't get there with power 58 00:02:59.280 --> 00:03:02.840 apps alone. The trick is deciding where just enough ends 59 00:03:02.879 --> 00:03:06.360 and overkilled begins. Let's look at something tangible, a loan 60 00:03:06.360 --> 00:03:09.800 approval platform, for example. Picture this. Your business has a 61 00:03:09.840 --> 00:03:13.199 proprietary risk scoring process that's been tweaked for years by 62 00:03:13.199 --> 00:03:16.400 the analytics team. There's confidential math, there are data pools 63 00:03:16.479 --> 00:03:20.120 from three sources, and the result needs to be calculated 64 00:03:20.319 --> 00:03:24.479 instantly every single time someone submits an application. Power apps 65 00:03:24.520 --> 00:03:27.360 can't handle that in a single flow or formula. So 66 00:03:27.919 --> 00:03:31.000 you build a slim interface in power apps where users 67 00:03:31.039 --> 00:03:33.960 key in application data. That data instantly shoots off to 68 00:03:34.000 --> 00:03:37.000 an as you're function where the heavy logic runs server side. 69 00:03:37.199 --> 00:03:40.280 Finished result comes back, gets displayed, and everyone's happy. You've 70 00:03:40.360 --> 00:03:43.960 kept the front and simple, shielded the secret sauce and 71 00:03:44.280 --> 00:03:48.159 your users see results right away. Under all, this data 72 00:03:48.199 --> 00:03:52.479 verse is humming along, organizing records, tracking changes, keeping audit trails. 73 00:03:52.879 --> 00:03:56.280 Data verse excels at making sure your data is reliable, 74 00:03:56.400 --> 00:03:59.240 current and accessible. What it can't do, though, is host 75 00:03:59.319 --> 00:04:02.960 resource hungry computations or orchestrate sequence logic that spans cloud 76 00:04:03.000 --> 00:04:05.879 and on premises apps. That's another natural handoff point to 77 00:04:06.000 --> 00:04:08.960 as your functions. So if you're sitting on databases that 78 00:04:09.120 --> 00:04:12.520 need shape shifting queries, or you want to transform data 79 00:04:12.560 --> 00:04:15.159 on the fly, the line gets clear power apps for 80 00:04:15.319 --> 00:04:19.839 interface and light workflow, data verse for structure, as your 81 00:04:19.920 --> 00:04:23.879 functions for magic tricks, but here's a twist. Sometimes people 82 00:04:23.959 --> 00:04:26.720 toss as your functions at every tough problem and end 83 00:04:26.800 --> 00:04:30.040 up with a spaghetti mess of services and endpoints. It 84 00:04:30.079 --> 00:04:33.519 feels powerful until you have to debug why a calculation 85 00:04:33.600 --> 00:04:36.720 took ten seconds longer today, or audit who changed what. 86 00:04:37.199 --> 00:04:41.560 Teams wind up with multiple functions overlapping or running out 87 00:04:41.600 --> 00:04:44.279 of sync, and soon nobody wants to touch the things. 88 00:04:44.480 --> 00:04:46.879 So the real challenge is judgment. Is this a gap 89 00:04:47.000 --> 00:04:49.279 that only custom code can fill? Or are you just 90 00:04:49.319 --> 00:04:52.240 piling on extra layers. If you pick your spots carefully, 91 00:04:52.319 --> 00:04:56.199 you get what every power apps project wants, a friendly 92 00:04:56.360 --> 00:04:59.279 user experience with fast screens and clear logic, and a 93 00:04:59.319 --> 00:05:01.279 back end that does and gas for air. The first 94 00:05:01.319 --> 00:05:04.160 sign of complexity. You walk the line between speed and 95 00:05:04.199 --> 00:05:07.240 custom power. It's all about understanding what each tool can 96 00:05:07.279 --> 00:05:10.560 and should handle when used with a purpose. Power apps 97 00:05:10.600 --> 00:05:13.720 and Azure functions together actually save time, traction for the 98 00:05:13.720 --> 00:05:17.240 citizen developer, muscle for the power user, and structure for 99 00:05:17.360 --> 00:05:21.240 it that loan app inventory system or custom pricing engine. 100 00:05:21.360 --> 00:05:24.360 They become approachable and user friendly without losing their teeth. 101 00:05:25.079 --> 00:05:28.959 But all this power only works if those parts really 102 00:05:29.000 --> 00:05:33.360 talk to each other. Securely, reliably, and at the right moments. 103 00:05:33.480 --> 00:05:36.160 So let's get into what actually happens when you wire 104 00:05:36.199 --> 00:05:38.680 these components together and what you have to watch out for, 105 00:05:38.800 --> 00:05:41.959 especially as data starts moving behind the scenes, how the 106 00:05:42.000 --> 00:05:46.199 pieces connect, data flow and secure communication. Here's where things 107 00:05:46.199 --> 00:05:48.759 start to get a little more real world than Microsoft's 108 00:05:48.800 --> 00:05:52.079 marketing slides ever show you picture this. Power Apps is 109 00:05:52.160 --> 00:05:55.480 humming along upfront, handing out forms and dashboards, with data 110 00:05:55.519 --> 00:05:59.480 Verse doing the grunt work in the background, filing all 111 00:05:59.519 --> 00:06:03.160 your business data into neat rows. But once Azure functions 112 00:06:03.160 --> 00:06:06.759 get involved, suddenly you've got sensitive info bouncing back and 113 00:06:06.800 --> 00:06:09.720 forth between moving parts that weren't all designed to trust 114 00:06:09.720 --> 00:06:11.959 each other by default. This is where the magic or 115 00:06:12.000 --> 00:06:14.720 the mess happens. A lot of folks think, I'll just 116 00:06:14.839 --> 00:06:18.240 drop the Azure function, URL into power Apps, set up 117 00:06:18.279 --> 00:06:22.079 a quick HTTP call, and boom, instant power up. The 118 00:06:22.079 --> 00:06:24.079 more you work with this stuff, though, the more you 119 00:06:24.120 --> 00:06:27.920 realize nothing is truly turn key, especially when security is 120 00:06:27.959 --> 00:06:31.600 on the line. One wrong click, one lazy shortcut on 121 00:06:31.680 --> 00:06:35.480 an endpoint, and you've left the vault door propped wide open. 122 00:06:35.920 --> 00:06:39.319 Stories float around the power platform community where someone thought 123 00:06:39.319 --> 00:06:42.920 a hard coded apikey would get them across the finish line, 124 00:06:43.279 --> 00:06:45.879 only to find out it gave every curious app in 125 00:06:45.920 --> 00:06:48.639 the tenant access they never should have had. Quite a 126 00:06:48.639 --> 00:06:50.879 few of those stories end with a data breach or 127 00:06:50.959 --> 00:06:54.160 the very least an emergency tier down when security comes sniffing. 128 00:06:54.480 --> 00:06:58.000 Power apps tries to make most connections safe and simple 129 00:06:58.079 --> 00:07:00.759 using out of the box connectors. These are great for 130 00:07:00.839 --> 00:07:04.120 data verse, SharePoint and the other usual suspects, but as 131 00:07:04.120 --> 00:07:06.240 soon as you step into the world of custom APIs, 132 00:07:06.319 --> 00:07:08.839 especially when you're running Azure functions, you're on your own 133 00:07:08.839 --> 00:07:12.240 for setup. Azure functions by default don't care who calls them. 134 00:07:12.439 --> 00:07:15.959 That's both their power and their flaw. Nothing is stopping 135 00:07:16.000 --> 00:07:19.079 someone from pointing Postman at your function endpoint and firing 136 00:07:19.120 --> 00:07:22.560 off a payload unless you layer on proper authentication. Now 137 00:07:22.639 --> 00:07:25.279 you have to manage tokens, define what data can come 138 00:07:25.279 --> 00:07:28.279 in and out, and keep your endpoints locked down. Let's 139 00:07:28.319 --> 00:07:31.680 ground this in something practically. Imagine your power app collects 140 00:07:31.720 --> 00:07:35.360 a customer number, then triggers an Azure function that fetches 141 00:07:35.480 --> 00:07:39.879 data from a legacy ERP system, maybe invoices, order histories, 142 00:07:40.079 --> 00:07:44.040 or approval statuses. The power apps ecosystem simply can't see directly. 143 00:07:44.600 --> 00:07:47.800 If that handoff isn't carefully managed, anyone with the endpoint 144 00:07:47.839 --> 00:07:51.079 can pull sensitive records. And let's be honest, there are 145 00:07:51.160 --> 00:07:54.959 IT departments still out there passing static apikeys between systems. 146 00:07:55.000 --> 00:07:57.639 It may work, but the dangers are clear. If that 147 00:07:57.759 --> 00:08:01.600 key leaks, either through an overlook GitHub repo or just 148 00:08:01.800 --> 00:08:05.560 sloppy code, it could be reused outside your network and 149 00:08:05.639 --> 00:08:08.120 no audit trails coming to save use. Security experts have 150 00:08:08.160 --> 00:08:13.079 a favorite solution, Managed Identities and all flows. Managed identities 151 00:08:13.600 --> 00:08:16.879 let Azure functions do what only they should do based 152 00:08:16.920 --> 00:08:20.279 on permissions assigned in Azure active directory, with automatic token 153 00:08:20.360 --> 00:08:24.279 rotation and no static keys hanging around. O ofth adds 154 00:08:24.279 --> 00:08:28.040 another layer, letting users or applications prove they're allowed to 155 00:08:28.040 --> 00:08:31.240 call your services on paper it's clean. In real life, 156 00:08:31.319 --> 00:08:35.039 setting up all between power apps and a custom Azure 157 00:08:35.039 --> 00:08:39.120 function isn't always documented clearly, and even seasoned architects have 158 00:08:39.240 --> 00:08:42.440 to triple check which permissions are needed and how those 159 00:08:42.440 --> 00:08:46.240 tokens are handled. You end up flipping between Azure portal tabs, 160 00:08:46.480 --> 00:08:50.440 stacking permission groups, and testing different endpoint responses just to 161 00:08:50.480 --> 00:08:53.399 get a single call through. It's not glamorous, but it's 162 00:08:53.440 --> 00:08:55.600 where the game is won or lost. Even with all 163 00:08:55.639 --> 00:08:58.840 the right patterns, every point where a power app or 164 00:08:58.879 --> 00:09:02.399 a Zoo function touches data verse, and especially any place 165 00:09:02.480 --> 00:09:06.200 data jumps across systems matters. Each one is an invitation 166 00:09:06.320 --> 00:09:09.080 for something to go sideways, whether it's an expired token, 167 00:09:09.399 --> 00:09:12.759 a muliformed payload, or an attacker sniffing for gaps. What 168 00:09:12.840 --> 00:09:15.679 people miss is that error handling starts with these boundaries. 169 00:09:15.720 --> 00:09:18.240 If your app expects clean data and a call to 170 00:09:18.320 --> 00:09:21.159 Azure function throws an error, users will either see cryptic 171 00:09:21.240 --> 00:09:24.080 error codes or worse, nothing at all. Now imagine a 172 00:09:24.120 --> 00:09:27.720 business critical app where that invisible failure means a missed 173 00:09:27.759 --> 00:09:31.120 deadline or a compliance breach. Let's talk about compliance for 174 00:09:31.159 --> 00:09:35.440 a second. In industries like finance or healthcare, just keeping 175 00:09:35.480 --> 00:09:37.759 things locked down isn't enough. You have to track and 176 00:09:37.879 --> 00:09:41.159 audit every access point, record every request, and prove that 177 00:09:41.240 --> 00:09:44.919 only authorized users can trigger certain logic. Without mapping your 178 00:09:44.960 --> 00:09:48.080 data flows knowing exactly what goes from power apps to 179 00:09:48.279 --> 00:09:51.639 Azure functions and via witch routes, you're mostly guessing when 180 00:09:51.679 --> 00:09:54.360 auditors show up. That's not the kind of adrenaline rush 181 00:09:54.360 --> 00:09:56.799 anyone wants. When you nail the setup, though, it feels 182 00:09:56.840 --> 00:10:00.480 like a proper system. Managed identities do their job behind 183 00:10:00.480 --> 00:10:03.960 the scenes, Data zips back and forth securely, and everyone 184 00:10:04.000 --> 00:10:07.600 can sleep a little better knowing that calls are authenticated, 185 00:10:08.039 --> 00:10:12.799 data contracts are respected, and error handling is at least predictable. 186 00:10:12.840 --> 00:10:17.440 In a perfect world, power apps focuses purely on orchestrating workflows, 187 00:10:17.840 --> 00:10:21.919 and UI data Verse manages the records and azure functions 188 00:10:21.919 --> 00:10:26.000 become trusty workhorses, never a security hole waiting to happen. 189 00:10:26.879 --> 00:10:29.200 But getting there is more about discipline than one off 190 00:10:29.200 --> 00:10:32.399 clever tricks. This is where a diagram saves the day. 191 00:10:32.759 --> 00:10:36.559 Walking through every hop your data takes, labeling which system 192 00:10:36.639 --> 00:10:40.200 needs authentication, and planning for what happens if calls fail. 193 00:10:40.960 --> 00:10:43.519 This is basic groundwork that pays off down the road. 194 00:10:44.120 --> 00:10:46.440 If your power app is wired to trigger as your 195 00:10:46.440 --> 00:10:49.679 functions that in turn hit other APIs or write back 196 00:10:49.720 --> 00:10:52.559 to data verse, every hob has to be mapped and secured. 197 00:10:52.919 --> 00:10:55.240 Get it right, and not only does your app scale smoothly, 198 00:10:55.279 --> 00:10:59.360 but compliance folks aren't sending daily slack messages asking about 199 00:10:59.399 --> 00:11:02.559 audit logs skimp here, though, and even the slickest app 200 00:11:02.600 --> 00:11:05.840 can turn into a liability fast. It's not paranoia, it's 201 00:11:05.840 --> 00:11:09.120 pattern recognition. Every connection is a risk and an opportunity. 202 00:11:09.360 --> 00:11:12.320 Think carefully about how data flows. Always enforce the right 203 00:11:12.399 --> 00:11:15.759 security protocols, and your app won't just function, It will last, 204 00:11:15.919 --> 00:11:18.720 But nobody gets it perfect the first try. So what 205 00:11:18.840 --> 00:11:22.720 happens if one piece in this system fails? That's where 206 00:11:22.720 --> 00:11:25.519 the real stress test begins. And if you don't plan 207 00:11:25.600 --> 00:11:28.919 for breakdowns early, you're in for some late nights when 208 00:11:29.519 --> 00:11:33.919 things go wrong, handling failures and avoiding maintenance nightmares. Let's 209 00:11:33.919 --> 00:11:36.480 say a user puts in data, hits submit on the 210 00:11:36.480 --> 00:11:39.879 power app and walks away thinking everything's done. But behind 211 00:11:39.879 --> 00:11:43.399 the scenes, your azure function throws an exception, maybe a 212 00:11:43.440 --> 00:11:46.519 timeout or a malformed payload, and power apps never gets 213 00:11:46.519 --> 00:11:49.600 a proper response unless you've wired up a clear error dialogue. 214 00:11:49.600 --> 00:11:51.600 The user won't see a thing. They may get a 215 00:11:51.600 --> 00:11:54.080 spinning loader that quietly gives up, or worse, a green 216 00:11:54.159 --> 00:11:57.159 check mark that means nothing. By the time someone realizes 217 00:11:57.200 --> 00:11:59.799 there's an issue, bad data might have trickled all the 218 00:11:59.799 --> 00:12:03.360 way to your reports, inventory system or compliance logs that 219 00:12:03.480 --> 00:12:06.559 confusion is common. If you haven't lived through the aftermath 220 00:12:06.600 --> 00:12:08.639 of a silent failure, you're in for a treat. The 221 00:12:08.679 --> 00:12:12.039 cleanup is always more complicated than you expect. Fusion development, 222 00:12:12.080 --> 00:12:14.799 for all its flexibility, sets you up for a special 223 00:12:14.879 --> 00:12:18.000 kind of pain. If error handling isn't a front burner topic, 224 00:12:18.159 --> 00:12:21.679 the fact is errors that happen inside as your functions 225 00:12:21.799 --> 00:12:25.480 are kept at arm's length from power apps. By default, 226 00:12:25.879 --> 00:12:29.679 there's no automatic channel that catches downstream errors and feeds 227 00:12:29.720 --> 00:12:32.440 them back to users. In Plane English, you might see 228 00:12:32.440 --> 00:12:34.399 red text for a failed connector, but when it's a 229 00:12:34.399 --> 00:12:37.720 custom function, the app often just sits there quietly or 230 00:12:37.799 --> 00:12:40.320 shows a vague error code that only makes sense to 231 00:12:40.360 --> 00:12:43.919 a developer. It's not uncommon to misfailures entirely. That means 232 00:12:44.000 --> 00:12:47.919 users keep working assuming their actions were processed, while the 233 00:12:47.960 --> 00:12:50.639 back end is full of partial jobs and missing records. 234 00:12:50.919 --> 00:12:54.120 This quiet failing creates a perfect storm for maintenance nightmares. 235 00:12:54.279 --> 00:12:57.000 You start off with a few functions and basic logging, 236 00:12:57.399 --> 00:13:00.919 and it almost feels manageable. But as the app landscape 237 00:13:00.960 --> 00:13:05.279 grows more azure functions bolted on different flows for each department, 238 00:13:05.559 --> 00:13:08.799 maybe a couple of extra connectors. For non Microsoft APIs, 239 00:13:09.080 --> 00:13:12.440 your error handling gets stretched thin. All those endpoints and 240 00:13:12.440 --> 00:13:15.200 triggers become minefields for hard to trace errors. It's like 241 00:13:15.320 --> 00:13:18.759 having fifteen different circuit breakers scattered through your house with 242 00:13:18.840 --> 00:13:23.039 no central panel. When something blows, you're running upstairs, downstairs, 243 00:13:23.080 --> 00:13:25.000 and out to the garage just to figure out what 244 00:13:25.080 --> 00:13:27.519 went wrong. A lot of teams try to fix these 245 00:13:27.559 --> 00:13:31.120 blind spots with band aid solutions. You'll see custom error 246 00:13:31.159 --> 00:13:34.360 screens popping up, especially in power apps, that catch generic 247 00:13:34.559 --> 00:13:37.960 errors and display as something went wrong, contact it message. 248 00:13:38.120 --> 00:13:41.519 Some go a step further by wiring in email notifications 249 00:13:41.559 --> 00:13:44.879 that fire on errors, but these measures seldom catch all 250 00:13:44.879 --> 00:13:48.399 the edge cases. For example, if an Azure function quietly 251 00:13:48.480 --> 00:13:51.840 locks a warning but doesn't throw a fatal error, your 252 00:13:51.919 --> 00:13:54.480 app might behave as if everything's fine, Or if the 253 00:13:54.519 --> 00:13:58.799 function itself is unreachable, maybe someone adjusted firewall rules or 254 00:13:58.840 --> 00:14:02.399 an expired certificate blocks the endpoint. Your app may just 255 00:14:02.480 --> 00:14:05.759 time out or hang, leaving users none the wiser. Consider 256 00:14:05.799 --> 00:14:08.480 the real world Dynamics three sixty five order system that 257 00:14:08.600 --> 00:14:12.240 relies on Azure functions for last minute inventory checks. One day, 258 00:14:12.320 --> 00:14:16.159 the function starts timing out intermittently due to increased load, 259 00:14:16.480 --> 00:14:18.840 orders keep flowing through the power app because the front 260 00:14:18.879 --> 00:14:21.840 end isn't programmed to handle those timeouts cleanly. The result 261 00:14:22.240 --> 00:14:25.639 inventory counts drift, the sales team starts over promising, and 262 00:14:25.679 --> 00:14:29.960 the back office starts seeing complaints from customers about missing shipments. 263 00:14:30.320 --> 00:14:33.320 At this point, grapping through log files is the only 264 00:14:33.360 --> 00:14:36.399 way to unravel what happened, and if logging wasn't robust 265 00:14:36.399 --> 00:14:39.559 from the beginning, the trail goes cold fast. Experts who 266 00:14:39.559 --> 00:14:43.240 have stitched together fusion architectures suggest designing for resiliency right 267 00:14:43.279 --> 00:14:46.200 out of the gate. That means building retry logic. So, 268 00:14:46.279 --> 00:14:48.639 for example, if an Azure function fails due to a 269 00:14:48.679 --> 00:14:52.559 temporary network issue, power apps tries again automatically instead of 270 00:14:52.600 --> 00:14:55.480 simply giving up. But it also means going further setting 271 00:14:55.559 --> 00:15:00.879 up centralized logging, maybe using Azure application insights or analytics, 272 00:15:00.919 --> 00:15:02.960 so you don't have to piece together what happened from 273 00:15:03.000 --> 00:15:07.639 scattered places. Most crucially, aim for clear error feedback inside 274 00:15:07.639 --> 00:15:11.919 power apps. Don't just pass along useless error codes. Translate 275 00:15:12.080 --> 00:15:15.240 errors into messages users can act on, so issues are 276 00:15:15.279 --> 00:15:19.080 surfaced early, not buried under routine clicks. Another big piece 277 00:15:19.240 --> 00:15:22.559 is having a single dashboard or monitoring tool where you 278 00:15:22.559 --> 00:15:25.519 can track what's healthy and what's failing across all your 279 00:15:25.519 --> 00:15:28.919 Fusion components. If an Azure function goes down, you want 280 00:15:28.919 --> 00:15:32.519 to know before users starts submitting support tickets. The bigger 281 00:15:32.559 --> 00:15:35.679 your Fusion project gets, the more small disconnects lead to 282 00:15:35.840 --> 00:15:38.720 hundreds of minor problems that eat up it hours. If 283 00:15:38.759 --> 00:15:41.559 all your error handling is scattered, fixing bugs becomes a 284 00:15:41.559 --> 00:15:44.399 whack a mole exercise, and no one remembers how the 285 00:15:44.440 --> 00:15:47.600 whole web fits together until something critical breaks, and then 286 00:15:47.639 --> 00:15:51.080 there's change management. As your app ecosystem matures, updates to 287 00:15:51.200 --> 00:15:54.679 Azure functions may impact power apps, logic, and vice versa. 288 00:15:54.799 --> 00:15:57.879 A rushed update to a function or a connector may 289 00:15:57.919 --> 00:16:01.480 introduce a new error path that wasn't logged or handled originally. 290 00:16:01.879 --> 00:16:05.759 Teams working on different pieces may not realize they're introducing 291 00:16:05.759 --> 00:16:09.759 maintenance issues until users start complaining. This is where robust 292 00:16:09.759 --> 00:16:13.600 documentation and disciplined change management make the difference between a 293 00:16:13.600 --> 00:16:16.559 smooth running system and the patchwork that only one person 294 00:16:16.600 --> 00:16:19.440 in it dares to touch. If you don't need enterprise 295 00:16:19.480 --> 00:16:23.759 scale overhead to build resilience in even simple practices like 296 00:16:24.360 --> 00:16:28.279 Logging every function invocation, setting status codes, and providing fallback 297 00:16:28.320 --> 00:16:30.720 paths for timeouts or failed calls can move you from 298 00:16:30.799 --> 00:16:34.679 reactive firefighting to proactive operations. The goal is to avoid 299 00:16:34.759 --> 00:16:39.320 the worst case scenario, silent errors that pile up, damage 300 00:16:39.399 --> 00:16:42.759 data quality, erode trust in your app, and keep support 301 00:16:42.799 --> 00:16:46.159 teams forever on the back foot. Ultimately, strong error handling 302 00:16:46.200 --> 00:16:48.919 isn't glamorous, but it sets the foundation for everything else 303 00:16:48.960 --> 00:16:52.799 in fusion development. A robust logging, meaningful feedback, and smart 304 00:16:52.840 --> 00:16:56.200 retry patterns let you sleep at night even as you 305 00:16:56.320 --> 00:16:59.480 add new connectors, tweak logic, or on board more users. 306 00:17:00.000 --> 00:17:02.639 On you've got that safety net in place, you can 307 00:17:02.679 --> 00:17:06.720 start thinking seriously about how to carve up your logic 308 00:17:06.799 --> 00:17:10.119 between power apps and as your functions without adding hidden 309 00:17:10.160 --> 00:17:14.119 costs or turning your architecture into a performance problem waiting 310 00:17:14.160 --> 00:17:20.000 to happen. Architecting for scale, performance, licensing, and strategic decisions. 311 00:17:20.200 --> 00:17:24.039 It's easy to think the answer is just to offload 312 00:17:24.079 --> 00:17:27.039 as much logic as possible into as your functions, especially 313 00:17:27.079 --> 00:17:30.960 after seeing where power apps hits its boundaries. But once 314 00:17:31.000 --> 00:17:35.319 you start shipping every bit of business logic, calculation and 315 00:17:35.359 --> 00:17:38.680 integration call to Azure, you're trading one bottleneck for a 316 00:17:38.680 --> 00:17:41.240 whole set of new ones. The performance trade offs hit fast. 317 00:17:41.599 --> 00:17:44.440 Every call out from power Apps to an Azure function 318 00:17:44.559 --> 00:17:47.000 is an extra hop over the network, and that hob 319 00:17:47.079 --> 00:17:49.200 isn't free. The time it takes for a round trip 320 00:17:49.240 --> 00:17:51.680 can stack up. Maybe it's a second or two, maybe 321 00:17:51.680 --> 00:17:54.799 longer if your function's cold, starting or waiting on another API. 322 00:17:55.359 --> 00:17:58.920 Users expect a form to process instantly, but if half 323 00:17:58.960 --> 00:18:02.279 a dozen as you're calls line up, suddenly they're staring 324 00:18:02.319 --> 00:18:05.200 at spinning wheels and wondering if the app is frozen again. 325 00:18:06.079 --> 00:18:08.920 Network blips, regional outages, or just a brief spike in 326 00:18:09.000 --> 00:18:12.119 load can multiply these delays, so it's more than just 327 00:18:12.200 --> 00:18:15.480 milliseconds on a clock. It becomes part of the user experience. 328 00:18:16.119 --> 00:18:18.400 What often gets swept under the rug is how quickly 329 00:18:18.440 --> 00:18:21.880 costs can spiral. As your functions sound cheap at first, 330 00:18:22.440 --> 00:18:26.680 and for hobby projects the bill barely registers. Scale up, though, 331 00:18:26.720 --> 00:18:29.480 and you'll notice the meter runs faster than people expect. 332 00:18:29.720 --> 00:18:34.640 Each invocation, each payload run, each integration trigger, it all counts. Meanwhile, 333 00:18:34.720 --> 00:18:38.559 power Apps enforces its own set of usage quotas and 334 00:18:38.599 --> 00:18:42.640 licensing levels, especially around API calls. The entry level plan 335 00:18:42.799 --> 00:18:46.440 includes a set number of requests per user per day, 336 00:18:46.559 --> 00:18:49.680 but you start hitting premium tiers if you connect to 337 00:18:49.680 --> 00:18:53.119 too many custom connectors, or if your usage pattern spike. 338 00:18:53.599 --> 00:18:57.359 It surprises people how a burst of popularity, a promo, 339 00:18:57.720 --> 00:19:00.599 a new department, on boarding, or even regular month and 340 00:19:00.720 --> 00:19:04.839 work can push you up into unplanned licensing territory. The 341 00:19:04.839 --> 00:19:06.960 sticker shock on that next invoice is real if you 342 00:19:07.000 --> 00:19:11.000 aren't watching closely. The harder problem isn't raw cost or latency, 343 00:19:11.279 --> 00:19:14.160 but figuring out which bits of logic have to live where. 344 00:19:14.440 --> 00:19:16.519 A good rule of thumb keep the stuff you want 345 00:19:16.599 --> 00:19:20.319 users to feel. Those instant validations. The small checks the 346 00:19:20.319 --> 00:19:24.319 conditional formatting inside power apps itself, things like did the 347 00:19:24.400 --> 00:19:27.240 user fill out all required fields? Or does this code 348 00:19:27.279 --> 00:19:29.720 match an approved value can be handled on the client 349 00:19:29.839 --> 00:19:32.920 side with almost no weight. This keeps the UI snappy 350 00:19:32.920 --> 00:19:35.559 and gives users the feedback they need right away. Any 351 00:19:35.599 --> 00:19:38.920 logic that needs to hit a large database, run expensive calculations, 352 00:19:39.240 --> 00:19:42.559 or interface with external APIs belongs in Azure functions. The 353 00:19:42.599 --> 00:19:45.160 line sounds clean on paper, but in real life it's 354 00:19:45.160 --> 00:19:48.319 always a judgment call. Then you have the integrations, the 355 00:19:48.319 --> 00:19:51.640 connectors that link to third party services outside Microsoft. I'll 356 00:19:51.680 --> 00:19:53.960 ask yourself, is this something that truly needs the muscle 357 00:19:54.000 --> 00:19:56.319 of Azure functions, or could I lean on an existing 358 00:19:56.359 --> 00:19:59.519 connector in power apps? Rolling your own custom function for 359 00:19:59.559 --> 00:20:03.160 every so feels powerful at first, but the maintenance, cost 360 00:20:03.240 --> 00:20:06.519 and failure modes stack up quickly. When you do need 361 00:20:06.519 --> 00:20:09.759 a custom connection, say a partner API that power Apps 362 00:20:09.960 --> 00:20:14.440 can't talk to. Natively move that communication to Azure Functions, 363 00:20:14.440 --> 00:20:16.559 but don't make it the default just because you can. 364 00:20:17.319 --> 00:20:19.359 Let's look at what happens when you get this division 365 00:20:19.400 --> 00:20:23.440 wrong by building everything into Azure. In one retail scenario, 366 00:20:23.799 --> 00:20:28.839 a chain wanted to guarantee that pricing calculations reflected current inventory, 367 00:20:29.039 --> 00:20:32.799 sales trends, and promotion rules. They pushed the entirety of 368 00:20:32.880 --> 00:20:37.160 the calculation logic out to Azure Functions. The accuracy jumped, 369 00:20:37.319 --> 00:20:40.039 They nailed their sales goals, and everything balanced at the 370 00:20:40.079 --> 00:20:42.799 end of the week. But the operations manager opened up 371 00:20:42.839 --> 00:20:45.319 the Azure cost dashboard and saw the bill had nearly doubled. 372 00:20:45.519 --> 00:20:49.119 All those micro calculations, including what could have been basic checks, 373 00:20:49.519 --> 00:20:52.839 went across the wire and racked up both Azure charges 374 00:20:52.880 --> 00:20:56.680 and API consumption on power apps licenses. When the architecture 375 00:20:56.680 --> 00:21:00.440 team re evaluated, they moved threshold checks and on screen 376 00:21:00.519 --> 00:21:04.119 logic back to power apps where possible. That simple shift 377 00:21:04.359 --> 00:21:06.759 dropped the bill back to normal and actually made their 378 00:21:06.799 --> 00:21:10.960 app feel faster. Building for scale isn't just about today's problems. 379 00:21:10.960 --> 00:21:14.079 It's about planning for spikes and keeping an eye on 380 00:21:14.079 --> 00:21:18.000 what you can't predict. Usage monitors, alerting for API thresholds, 381 00:21:18.039 --> 00:21:22.079 and monthly cost reviews aren't optional skills anymore. It's frustrating 382 00:21:22.119 --> 00:21:24.839 to be caught off god because a seasonal rush or 383 00:21:24.960 --> 00:21:28.319 one well meaning automation blows up your licensing allocation. Even 384 00:21:28.400 --> 00:21:32.079 seasoned teams end up surprised when tweaks that look small, 385 00:21:32.160 --> 00:21:35.920 like moving one validation outside power apps, quietly shift the numbers. 386 00:21:36.440 --> 00:21:39.119 Architects who've been through a few of these projects will 387 00:21:39.160 --> 00:21:42.519 tell you they've learned to sketch out logic maps ahead 388 00:21:42.519 --> 00:21:45.759 of time and to ask uncomfortable questions about which team 389 00:21:45.880 --> 00:21:49.799 owns each piece. The goal isn't just to keep things running, 390 00:21:49.839 --> 00:21:54.000 but to prevent an accidental drift into an architecture that's slow, expensive, 391 00:21:54.039 --> 00:21:56.759 and a pain to troubleshoot. This doesn't mean refusing to 392 00:21:56.880 --> 00:21:59.559 use as your functions, far from it. It's about drawing 393 00:21:59.559 --> 00:22:03.079 clear bad for those high effort, compute heavy workflows, or 394 00:22:03.119 --> 00:22:06.960 anything that needs top notch security or hits multiple systems, 395 00:22:07.000 --> 00:22:10.079 Azure Functions is the right tool everywhere else, ask if 396 00:22:10.079 --> 00:22:13.440 the added overhead is justified. Future Proofing your app also 397 00:22:13.480 --> 00:22:17.319 means watching for change. Licensing plans can shift, product limits 398 00:22:17.359 --> 00:22:20.640 get tweaked, and what's cost effective today? Might sting in 399 00:22:20.680 --> 00:22:24.799 a year, set up dashboards, regular reviews, and put some 400 00:22:24.880 --> 00:22:28.119 heads together before expanding a fusion project to new use cases. 401 00:22:28.279 --> 00:22:31.960