What began as a simple weekend Power Platform lab quickly turned into one of the most educational projects
I've completed in a long time.
The original goal was straightforward. Build an equipment inspection application using Power Apps,
SharePoint, and Power Automate. An inspector would select a piece of equipment, record inspection results,
add comments, take photos, and submit everything from a mobile device.
On paper, it sounded like a relatively small project.
As with many technology labs, the real learning happened once I started building.
The first challenge appeared while designing the data model. I created an Equipment list and an Inspections
list in SharePoint. The relationship seemed simple enough. An inspection would reference a piece of
equipment using a lookup column. That decision introduced my first deep dive into SharePoint lookup fields
and how Power Apps handles them.
At first, I assumed I could simply save the equipment name as text.
Unfortunately, SharePoint had other ideas.
I quickly learned that lookup fields aren't simple text values. Behind the scenes, SharePoint expects a
record containing both an identifier and a display value. Once I understood how lookup columns actually
work, a lot of Power Apps behavior that previously seemed confusing suddenly made sense.
The next challenge involved person fields.
I wanted the application to automatically record the inspector performing the inspection. Power Apps and
SharePoint don't simply exchange a display name for person fields. Instead, they pass a structured user
record containing claims, display names, email addresses, and other metadata. Like the lookup field problem,
understanding the underlying structure proved far more valuable than simply finding a block of code that
worked.
Just when things appeared to be coming together, another design decision surfaced.
Should inspection results be stored as a Yes/No field or a Choice field?
Initially, I chose a Yes/No column for Pass/Fail results. Technically it worked, but the resulting
SharePoint list wasn't very intuitive. A passing inspection displayed "Yes" while a failed inspection
displayed a blank value. It quickly became obvious that the data model wasn't accurately representing the
business process.
The solution was surprisingly simple.
I replaced the Yes/No field with a Choice field containing Pass and Fail values. The user experience
immediately became better, and the underlying data more accurately reflected the inspection process
itself.
With the inspection record functioning correctly, I moved on to photo capture.
What initially sounded easy turned into one of the most interesting parts of the entire project. Capturing a
single photo was straightforward. Capturing multiple photos while limiting the user to four images required
a little more thought. Eventually the design evolved into a dedicated photo screen where inspectors could
take up to four photos, preview them, delete them, and replace them if necessary.
The application worked perfectly in Power Apps.
The next challenge was getting those photos into SharePoint.
I created a document library called Inspection Photos and began experimenting with Power Automate. The first
file uploads appeared successful, but every image was corrupted. The files existed, yet SharePoint couldn't
open them.
That rabbit hole turned out to be one of the best learning experiences of the project.
After several rounds of troubleshooting, I discovered that Power Apps was sending images as JSON strings
containing Base64 encoded image data. The flow needed to strip extraneous characters, remove the image
header information, decode the Base64 content, and convert it into binary data before SharePoint could
create a valid image file.
Once the conversion process was corrected, everything immediately started working.
Real PNG files began appearing in the document library.
At that point, another challenge emerged.
The document library contained photos, but those photos weren't yet connected to inspections in a meaningful
way. Every inspection could have between one and four photos, and every photo needed to be associated with
both the inspection and the equipment being inspected.
The final design used metadata stored alongside each image.
Inspection records received unique identifiers. Photos were named using the inspection identifier and stored
metadata values for both Inspection ID and Equipment ID. The result created a clean relationship between
Equipment, Inspections, and Inspection Photos.
The most satisfying moment came when I stepped outside onto my deck and tested the application on my actual
phone.
I selected a piece of equipment, recorded a failed inspection, entered comments, took multiple photos, and
submitted the record. Seconds later, the inspection appeared in SharePoint along with every photo, all
properly linked through metadata.
That moment transformed the project from a development exercise into a working solution.
Looking back, very little of the learning came from clicking buttons or following instructions.
The most valuable lessons came from understanding why things weren't working. Lookup fields, person fields,
Power Automate, image conversions, metadata relationships, and mobile device testing all presented problems
that forced deeper investigation.
What started as a simple equipment inspection app became a hands-on lesson in data modeling, SharePoint
architecture, Power Apps development, Power Automate integration, and mobile application design.
More importantly, it reinforced a lesson I've encountered repeatedly throughout my technology
journey.
The best learning rarely comes from success.
The best learning comes from the moment something doesn't work and you're determined to figure out
why.
By the end of the project, I had built a fully functioning mobile inspection system capable of recording
inspections, capturing photos, storing evidence, and maintaining relationships between equipment,
inspections, and supporting documentation.
Not bad for a weekend lab that originally started as a simple Power Apps experiment. 🐦🐦