MailStop

NASA Langley routes all internal mail through MailStop IDs. The app that managed them ran on Oracle APEX from 2011. I rebuilt it on Microsoft Power Apps to drop the Oracle licensing cost and let staff maintain their own assignments.

3,400 people, 190 buildings

Every piece of mail moving inside NASA Langley is sorted by a MailStop ID, which maps a recipient to one of 190 buildings, down to their room and department, for more than 3,400 staff.

The app that managed all of that was built with Oracle APEX in 2011, and it looked it. Rising license costs, plus a very 2011 UI, put migration on the table.

I rebuilt it as a Microsoft Power App on a SharePoint Lists backend, since Langley already has a strong Office 365 agreement. Along the way I redesigned the data model and the search, so staff and admins could find their own assignments without asking anyone, which matters a lot somewhere buildings are constantly being renovated and departments constantly reorganized.

LaRC Mailstop landing screen with an Open button — Landing screen, showing the current app version so staff can mention it in a bug report.

Paginated table of MailStops with search and filter controls — Main list. Search by ID, filter by building or organization.

The trap is called delegation

The hard part wasn't the frontend, though the frontend was tedious. It was the backend swap. The APEX app sat on seven related Oracle tables, and SharePoint Lists is flat storage rather than a relational database, so every join the old schema relied on had to be reimplemented inside the Power App itself.

Then there is the trap. Power Apps can only push some queries down to SharePoint. Anything it can't delegate gets evaluated against the first 500 rows (2,000 at most), and you get a small warning icon.

And no error.

With 3,400+ people in the data, a careless filter means somebody's MailStop silently does not exist. That one constraint drove most of the design.

Rebuilt the seven-table Oracle schema as SharePoint Lists, moving all relational logic into the app layer since Lists can't enforce it.
Made the MailStop list filterable by ID, building, or organization, and paginated it. Besides performing better, it turns finding a particular stop into a quick search instead of a tedious (boring) scroll.
Added a validation view that surfaces the records the old system let rot: missing point of contact, no assignees, invalid building, invalid room.
Put mandatory-field checks, an offsite toggle, and POC search into the create flow, so entering a bad record is harder than entering a good one.
Wrote a manual regression checklist to run before every release. Power Apps' automated testing tools weren't practical for this app, so the test suite is a long, very thorough document.

Screens

Detail view for a single MailStop — MailStop details: assignees, group, created by, creation date, last modified date, point of contact (POC), and remarks.

Edit form for a MailStop record — Editing a record: offsite toggle, group swap, POC reassignment, and remark changes.

Create form with required fields and a person search — Create flow: mandatory field checking and quick POC search.

Record flagged in red for a missing point of contact — Validation showing a record with no point of contact.

What low-code gives and takes

Low-code gave this a quick, cheap turnaround and handed Langley something staff with no programming experience can maintain after I leave. That was the entire point, and it worked.

What it does not give you is schema-level constraints, relational logic inside the database, or any way to test the thing that isn't a person with a checklist. With more time, I'd push more validation down into the data layer instead of trusting every write path to remember to check.