One of the hardest challenges as a Power App Developer is translating customer requirements into solutions that don’t make users want to put a brick through their monitor. This often means finding MacGyver-level workarounds for environments more complex than a battlefield intelligence analysis. As someone who’s traded in my beret for a keyboard but still maintains that battle-ready mindset when facing Microsoft’s ecosystem, let me walk you through my latest SNAFU with Power Apps and Power Automate.

The objective was straightforward on paper: update a document library with an AI-processed PDF attachment while incorporating a CON-prefixed ID and extracting metadata. Simple enough for the drowsy wizard who wrote the outdated Microsoft docs to explain clearly? Nope, not quite. What began as a standard operation while building my demo for prospective work quickly turned into a FUBAR situation thanks to undocumented bugs and half-baked preview features that Microsoft deployed without proper testing. My initial strategy was to leverage Power App Fx to directly manipulate a SharePoint document library, a common use case that I approached with the same enthusiasm as a coder with a fresh API key and hefty budget.

First attempt: attach a PDF processed via AI Builder’s OriginalImage to a SharePoint list item while generating a CON- prefixed ID. I deployed Power Fx’s Patch function, constructing a table with ContentBytes from the aiPDFUpload variable:

This was about as effective as trying to dig a foxhole with a plastic spoon. Power Apps immediately told me to pound sand but here’s the catch, it didn’t tell me why other than the fact it 404’d, the GET request worked but the POST didn’t albeit it was the same URL with the same accurate ID. I had to dig for this answer and thankfully Matthew Devaney’s blog clarified the situation, it was because attachments can’t be patched directly; they require a form control. Even when I pivoted and used a form control, I still couldn’t assign the attachment. I tried this code to assign the form’s item property:

But there was still the small problem of converting Base64 data and adding it as an attachment. At this point, I was mainlining Red Bull and considering whether PL-400 certification actually stood for “Pain Level 400.”

Reassessing the situation, I took a step back, walked the dog and decided to ditch the document library in favor of a SharePoint list. This wasn’t just a technical decision; I was thinking about the end users who needed something functional rather than fancy. I went back to the Patch function attempt, only to get slapped down again by Power Apps’ limitations. It was like running into digital concertina wire, painful and impossible to ignore.

Next, I tried a SharePoint calculated column for the CON- prefix using =”CON-“&TEXT(ID,”000”). This looked like an elegant yet old fashioned solution on paper, about as promising as a well-designed flowchart in a project plan. But reality bit hard when I realized the ID field isn’t available during calculation, which leads to a CON- but no ID shown in the created item. This isn’t a bug; it’s a “feature,” according to Microsoft’s docs, which I should’ve read with the same attention I once gave to TSC-185 field manuals. Meanwhile, relying on Last('Concept Vault') to target new records proved about as reliable as getting that early off e-mail on a friday for a holiday weekend. Why? Well because Last function simply targets the item most recently in cache, which is inefficient as it could be someone else created a list item while you were working.

The real mess in the flow came with Microsoft’s unintuitive parameter naming in Power Apps (V2) triggers, generating text, text_1, etc., despite renames of the initial input variables to trigger the flow. Bug? I’m not sure but the job for the day isn’t to dig deeper into internal names but to get this demo running. The Attachment control’s dependency on a Form was another surprise that forced me to completely rebuild my UI, making me question if Microsoft’s UX team had ever actually used their own product.

Finally, I had a breakthrough that would make any NCO proud: work with the terrain you have, not the terrain you want. I designed a Power Automate centric approach where Power Apps passes FormProcessor1.OriginalImage (Base64 data), the flow creates the SharePoint item, converts the data with dataUriToBinary(triggerBody()?['text_2']), and returns the ID via “Respond to a PowerApp.” For the CON- prefix, I abandoned the calculated column in favor of setting it in the flow with concat('CON-', string(triggerOutputs()?['ID'])). Sometimes you need to approach the problem from a completely different angle and with deadlines always looming, you simply can’t think too hard about failed approaches.

After two days of combat with Microsoft’s documentation and debugging tools that make an MRE spoon look sophisticated, I finally had a working solution. A “simple” task that should’ve taken hours stretched into days, requiring forum diving, test deployments, and monitoring inputs/outputs like I was endlessly pushing a boulder up a hill. Call me Mr. Sisyphus. It just goes to show that even with an extensive knowledge of Microsoft documents, a PL-400 certification, and the stubbornness that got me through basic training, what you need most as a Power App Developer is a willingness to suffer and enough caffeine to fuel a mechanized division.

My approach reflects how I operate in any technical environment, I start with the tools I know best, like Power Fx for text manipulation, but I’m not too proud to call in specialized support (Power Automate) when the situation demands it and if the environment allows it, I dust off my C# skills. Each step gets validated with proper debugging and finally you throw in some IfErrors to catch those black swan scenarios. The final victory came from embracing the platform’s limitations rather than fighting them, like learning to work within STIG policies instead of constantly crying about them. It’s this blend of technical discipline and battlefield adaptability that lets me deliver solutions that actually work, not just look good in briefings. If you enjoyed this read, stay posted. I will be posting more experiences along the way for demos I am presenting to showcase my skills and if you’d like to hire me, I am open for opportunities!