Operational visibility dashboards and admin tools

This was the visibility workstream for the same internal operations platform. If floor work happens through scans, quality decisions, and production records, office users should not need to ask for the latest spreadsheet to know what is happening.

The dashboards and admin tools sat on top of the same records used by shipping, quality, inventory, and related operations. They helped users answer practical questions: what is ready, what is blocked, what changed recently, and which exception needs attention.

Artifact note: screenshots, data examples, and code seams below are public-safe reconstructions of the production workflow. Actual UI, identifiers, customer data, and private table names are redacted; the query/filter design, status summaries, and backend boundary reflect the implementation work.

What the screens replaced

Before:

• Someone wrote or scanned operational data.
• Another person updated an Excel file or sent a message.
• Office users checked the spreadsheet, email thread, or messenger chat.
• If the information looked stale, they asked the floor again.

After:

• Operational actions updated backend records directly.
• React dashboards and admin screens read those records through NestJS APIs.
• Users filtered by status, date, work area, shipment, item, or exception type.
• The latest operational status was visible on the website with exception-heavy views surfaced first.

My ownership

My work focused on full-stack delivery for the visibility layer:

• React/TypeScript dashboard and admin screens;
• API-connected status summaries and filters;
• reusable table, form, modal, and status-badge patterns;
• role-aware actions tied to backend permissions and validation;
• production debugging when a screen did not match user expectations;
• alignment with shipping, quality, receiving, and inventory state models.

Artifact: dashboard surface

Artifact: data path

The important design choice was that the dashboard never became a second spreadsheet. It summarized backend records and sent actions back through API validation.

React route
  -> URL filters: area, date, status, exception type
  -> GET /api/operations/status-summary
  -> render counts, exception table, and drill-in actions
  -> user opens row action modal
  -> POST action to validation endpoint
  -> refresh summary from backend state

Simplified from the production data shape; field names and identifiers are changed.

type OperationalStatusBucket = {
  key: "ready_to_ship" | "in_production" | "quality_hold" | "blocked";
  label: string;
  count: number;
  severity: "normal" | "warning" | "critical";
  href: string;
};

type ExceptionRow = {
  workItemId: string;
  area: "production" | "shipping" | "quality" | "inventory";
  currentStatus: string;
  blockedReason?: string;
  nextAction: "review" | "release" | "assign" | "wait";
  lastUpdatedAt: string;
};

This is more concrete than a generic status card: the UI had to reflect operational questions, backend permissions, and records that other modules also depended on.

Operational story

A dashboard user might start the morning by filtering for quality holds and blocked shipments. Instead of asking multiple people for updates, the screen showed the current exception list, the affected work item, and the next action path. When a user acted through the modal, the API validated the transition and the dashboard refreshed from the same backend source.

The engineering value was visibility as a product surface on top of real operational state, not a decorative reporting page.

Outcome

These screens supported daily operational visibility for office users in a production environment with 60+ total users across office and factory-floor roles.

• Status checks moved from messenger, Excel, and email updates into dashboard and admin screens.
• Users could find blocked or exception states through filters, tables, badges, and action modals instead of scattered communication.
• Frontend status displays stayed tied to NestJS APIs and PostgreSQL records instead of becoming another spreadsheet-like source of truth.
• The reusable full-stack pattern was query/filter design plus backend-backed admin actions for users who need to make decisions from shared records.