Division Hold Management Tool

Sherlock 2.0 automatically assigns field inspections across PG&E’s divisions. But in practice, teams sometimes need to temporarily pause scheduling for specific divisions because of audits, staffing changes, operational constraints, or weather-related disruptions.

Before this tool, handling those pauses required manual workarounds or engineering intervention. I designed and implemented a division-level hold system that gave authorized users a safe, self-service way to manage scheduling behavior without touching the core assignment logic.

The challenge was not just adding another admin control. The feature had to fit into an existing production system, work with Sherlock’s scheduling architecture, and make operational changes without creating confusion or unexpected side effects.

The goal was to give teams flexibility while still preserving trust in the broader assignment pipeline. That meant the solution needed to be clear in the UI, reliable in the backend, and easy for users to understand at a glance.

I built a self-service hold management workflow where users could select one or more divisions, apply a hold reason, and later release those divisions individually or all at once. The tool integrated directly into Sherlock 2.0’s existing architecture and enforced holds through dynamic query updates rather than invasive changes to the assignment logic itself.

On the frontend, I focused on making status visibility really clear: users could immediately see which divisions were available, which were on hold, and what actions were possible. On the backend, I modeled the hold records, API interactions, and state handling needed to make the tool reliable and safe to use in a real operational environment.

The tool combined a simple management interface with backend record handling to make division-level scheduling controls visible, traceable, and easy to update.

This project pushed me to think beyond just implementing a feature. I had to think about how to introduce flexibility into a production system without making that system harder to trust. That meant being careful about architecture, user flows, and the small details that make an internal tool feel dependable.

It also reinforced something I really enjoy: building software that sits at the intersection of systems thinking and user experience. The most satisfying part of this project was creating something that felt technically sound but also immediately useful to the people actually doing the work.