The Work
Start with a record people could maintain
The initial records included part number, serial, location, equipment type, status, revision, customer, and notes. I built a common workbook template and populated classifications from the selected part number so people did not have to retype the same information on every intake.
Serial number became the stable identifier for synchronization. I documented that it could not be blank or casually changed. Status and physical location also needed to remain separate: a part could be out of one station’s stock while being sent to another location.
I wrote workbook instructions explaining the fields and their dependencies. Standardizing the sheet mattered as much as the later automation because inconsistent source records would simply become inconsistent records in a larger shared list.
Update the existing part instead of adding another copy
I initially considered keeping the consolidated inventory in Excel, but refresh behavior varied with user permissions. Moving the shared records to SharePoint gave the automation a common destination.
I used Power Automate to collect each station’s workbook rows and compare them with the master SharePoint list twice daily. When a serial already existed, the flow updated its record; when it did not, the flow created one.
That distinction addressed an immediate failure mode. If every status change created a new row, an installed part could appear both in stock and out of stock. Matching the existing record was the foundation for making the shared inventory useful.
The shared list could be filtered across locations and equipment types, but it did not remove much of the station employee’s intake effort. That was why I continued into an application rather than treating consolidation as the finished solution.
Make the common actions visible
The Power Apps screen combined a searchable item list with the selected part’s detail form. Filters covered location, equipment type, variation, and status. The overview used Power BI stock charts with minimum and maximum indicators, while counts on the main screen followed the selected location.
Receiving, editing, and installation were separate actions. Edit mode exposed save and cancel controls. Switching between the in-stock and installed lists reset the filters, and selecting another item reset editing and installation flags so an abandoned action did not carry into the next record.
I spent months refining behavior after the initial working version. I documented how the selected record, form state, and background flow interact so the application could be maintained as the workflow developed.
Handle the interrupted path as well as the successful one
Before installation could continue, the user had to verify the selected part. The confirmation button remained disabled until that check was complete. Canceling the action reset the selection flags and verification checkbox.
Installation required a status change, creation of an OUT/RMA record, preservation of attachments, and an archive record. During testing, I found a condition that repeatedly triggered the flow. I added a processed-state check to address that loop.
I also disabled the confirmation action while background work ran and used the flow’s returned record identifier to continue the application. If the response was blank, the interface notified the user and reset the relevant flags instead of navigating as though the operation had succeeded.
These controls kept the selected part, its status, and the background record changes aligned when an action was canceled or a response failed.
| Action | Record behavior | Control or recovery path |
|---|---|---|
| Synchronize a station workbook | Update an existing serial or create a new record | Keep serial numbers stable and distinguish status from location |
| Edit or select a different part | Save or cancel changes to the selected record | Reset edit and installation flags when the selection changes |
| Install a part | Change status, create OUT/RMA and archive records, preserve attachments | Processed-state check prevents the repeated flow trigger found during testing |
| Wait for the background flow | Use the returned record identifier to continue | Disable confirmation during processing; notify and reset flags if the response is blank |
At a glance
Follow a part through the shared record
- Receive and identify
Station workbooks use common fields, with serial number as the stable record identifier.
- Match or create
Twice-daily synchronization updates an existing SharePoint serial or creates a new record.
- Edit or install
The app separates save and cancel from verified installation; changing selection clears unfinished action flags.
- Complete the record
Installation changes status and creates OUT/RMA and archive records while preserving attachments.
A processed-state check addresses a repeated flow trigger. A blank flow response notifies the user and resets the relevant flags instead of continuing as if the action succeeded.
THE DELIVERABLES
What I delivered
- Standardized workbooks and field instructions for six stations.
- Twice-daily workbook-to-SharePoint synchronization using serial-number matching.
- Power Apps inventory interface with intake, editing, installation, and archive workflows.
- Power BI stock overview and documentation of interface state, record movement, and failure handling.
A CLOSER LOOK
Project exhibits
Move from stock review to the part record
The inventory screen brings search filters, item cards, and the selected part’s details together. The Install Part action connects stock review to the installation workflow.
THE OUTCOME
Where the work stands
Built a shared inventory and an application that connects stock review to the receiving and installation workflow, with the logic documented for continued refinement.
SCOPE AND LIMITATIONS
What the work establishes
Receiving inspections and required station records remain part of the workflow alongside the application.