QA/QC Inspection Scheduling System

2026-Present Professional · Internal Tools / Workflow Architecture

I joined OEG as a Site Administrator and found an inspection-request process built around calls, incomplete emails, manual follow-up, and inconsistent scheduling visibility. I originated the replacement and pitched it to site leadership. After gathering requirements, I built and demonstrated prototypes as sole developer, then carried the system through implementation, launch, support, and a later platform migration.

The product evolved across platforms as its operating constraints changed.

First milestone: a production Microsoft 365 application

I began with a rapid Forms-and-Excel prototype. Stakeholder feedback expanded the requirements to include type-ahead personnel lookup, which the original approach did not support well, so I changed the architecture before launch rather than force the requirement into the wrong interface.

The launched version used Microsoft Lists as its system of record and Power Automate as its workflow layer. Field personnel submitted requests through a mobile-friendly form. Management reviewed status, approval, and scheduling in Lists. Approved schedule changes were published one-way to a shared Outlook calendar for read-only field visibility.

  • Structured intake replaced calls, incomplete messages, and manual transcription
  • Validation, normalization, mappings, and notifications ran after record creation
  • Human approval and scheduling remained separate from automation
  • One operational record drove multiple management and field-facing views

The organization boundary became an architecture requirement

After launch, the workflow needed to support Praetorian, a third-party QA/QC partner. Corporate Microsoft tenant controls did not support the operational access the external team required. The Microsoft version had worked and launched; the new constraint did not erase that milestone. It changed what the next version had to do.

I rebuilt the workflow natively in Smartsheet so intake and controlled operational participation could cross the company boundary without creating an unmanaged second source of truth. The rebuild centers on one operational sheet within Smartsheet, supported by a streamlined intake form and durable request identifiers with generated, human-readable titles. Status visualization, attachments, notifications, and calendar reporting remain in the same governed workflow.

The migration is complete. QA/QC now runs entirely in Smartsheet, and the former Microsoft implementation has been retired and removed. Field personnel submit inspection requests through the Smartsheet form.

The current form and sheet are being refined around field requirements. Required attachments, notification delivery, external editing, and calendar behavior remain part of the validation work. A completed platform migration does not establish organization-wide adoption or measured time savings.

Migration without losing the product model

The Microsoft launch established the data model, field vocabulary, and scheduling states. Its notification needs and operating rules also carried forward. What changed was the platform boundary and the amount of custom automation required.

The Smartsheet design favors native formulas, views, reports, and focused workflows. Access remains part of the release model: participants must be able to work with the records and attachments they need without receiving unnecessary internal access.

A companion for field personnel

SiteLine is the companion directory I built for this workflow. Field personnel use it to find contacts and take direct communication actions. It remains a separate Power Apps application with its own Microsoft List; QA/QC's platform migration did not retire the directory.

What this demonstrates

  • End-to-end product ownership as sole developer
  • Stakeholder discovery, demonstrations, feedback translation, and launch support
  • Production delivery with Microsoft Lists, Power Automate, and Outlook
  • Smartsheet intake and workflow design, with permissions suited to cross-company use
  • Architecture decisions driven by identity, access, and cross-organization workflow
  • A willingness to migrate a working product when the operating environment changes