Purpose
Give frontline technicians a clean, filtered operational interface for staff device refresh execution.
Current state
The portal is in active production use alongside the staff technology dashboard. Registry refinements clarify a structured operating model: identify upgrade candidates, confirm readiness, segment direct-swap users versus migration-support users, and execute site rollout waves with technician-facing worklists.
Next step
Document the operator model in runbook form: status write-back location, daily handoff cadence, segmentation rules for direct swap vs migration support, and ownership of the shared extract contract.
Interfaces
Inputs- staff/device extracts
- role or site access rules
- status fields and swap-list views
Outputs- technician worklists
- swap lists
- status snapshots
Reality to Action trace
Reality IngestionContributes in this stage.
Canonical StorageNot in scope.
Automation EnginesNot in scope.
Human InterfacesContributes in this stage.
Operational AdoptionContributes in this stage.
Core workflow
TBD. Document the 5-10 steps that define the core workflow.
Data integrity and contracts
Source of truth rules
- Shared staff/device extracts are canonical for portal inputs.
- Access-rule tabs are authoritative for technician visibility.
- Operational status fields in the portal sheet should be treated as the execution record when used.
Safe handling
- Restrict access by technician role and site scope.
- Avoid exposing staff-device details outside internal operations surfaces.
- Document who can edit status fields and how corrections are reviewed.
Operational notes
Reliability posture
The portal is operationally useful, but depends on a stable shared extract contract and disciplined status-field usage.
Observability
- sheet refresh timestamps
- Apps Script logs
- visible stale or filtered-data issues in worklists
Security and privacy
Technician views should stay limited by site and role. Staff-device assignment and scheduling context remain internal operational data.
Dependencies
Upstream- BOUSD-Staff-Technology-Dashboard extract cadence
- sheet access rules
- current inventory data
Downstream- refresh campaigns
- daily technician handoff
- leadership progress tracking
Ownership
OwnersTechnology Services, Josh Barton
UsersIT technicians, site support staff, IT leadership
Staff Device Refresh Operations Portal
Operational Notes
- This is the technician-facing execution layer paired with BOUSD-Staff-Technology-Dashboard. The registry now places the broader refresh workflow on a scheduled extract cadence rather than a purely manual spreadsheet process.
- The portal matters because it turns reporting into execution. Site- and role-filtered worklists, swap lists, and status views reduce technician overhead and failed appointments by distinguishing swap-ready users from users needing migration help.
- Operator model: campaign leads and technicians act on refresh cohorts, confirm readiness states, and move status fields through rollout stages during active waves.
- The main remaining uncertainty is the execution contract: where technicians write status, how handoff happens during refresh waves, and which fields are treated as the canonical operational record versus mirrored reporting state.
Registry Alignment
- Mapped registry entry:
INT-032. - Registry clarified: this page is an active production operations surface, not only a workflow concept.
- Validation gaps: status write-back behavior, daily handoff cadence, and canonical extract contract ownership still need documentation.
