Single Pane of Glass
Callers don't know the site number — they know a street, a town, a branch name. Search how they talk; the site number comes back, and everything else opens with it. Nothing here is behind a tab.
Site — none selected Excel — Branch Directory
Emergency Contacts Excel — Branch Directory
Contractors On Site SharePoint — Contractor Log
Recent Activity SharePoint — SOC Log
Alarm History SharePoint — SOC Log
New Log Entry replaces the Power App
SOC Log SharePoint — SOC Log
| Time | Site | ATM | Type | Narrative | WO | Emp |
|---|
Branch Directory
The full spreadsheet. In practice you reach a branch by searching the console — this is the reference list behind it.
| Site | Branch | Address | Branch Mgr | PD | Fire | Security |
|---|
Why Consolidate
The argument, in operator terms.
Today — four places
- SOC log (SharePoint) — every call, chronological, one long table
- Contractor log (SharePoint) — separate site, separate tab
- Branch directory (Excel) — addresses and every emergency contact
- Intake form (Power App) — writes to the log, but you leave to use it
- Nobody calls in a site number, so every call starts by parsing an address into a key
Proposed — one pane
- Search the way callers speak; the site number is returned, not required
- Lock the site once — the log, contractors and the form all follow it
- On-test status sits beside the alarm, not two tabs away
- Every emergency contact is on screen while you're on the call
- The entry form is on the same pane as the data you're logging about
How it would be built
Nothing moves. The SharePoint lists stay the system of record and the Power App keeps writing to them. This reads through the standard APIs — no migration, no duplicate database.
Permissions are inherited. It shows exactly what each person can already open; the console arranges access, it doesn't grant it.
Read-only first. The consolidated view can ship and prove itself before anything writes back.
Alarm history needs no integration. Every alarm is written up in the SOC log anyway, so a site's alarm history is already in our own records — it only needed surfacing, and it now sits beside the contractor status. That also makes it the record we control: we have had to verify the vendor against our own log before. Pulling signal-level data from Vector would add depth, but it needs a vendor conversation and is scoped as a follow-on so it can't hold up anything here.
Known next problem: work-order numbers have the same discoverability gap as site numbers — nobody has one to hand. Searching them by description is the obvious follow-on once this exists.