The notification system behind every wildfire shutoff in San Diego County.
San Diego Gas & Electric serves 3.7 million homes and businesses across 4,100 square miles of Southern California. Beautiful country; also some of the most fire-prone terrain in the United States. When meteorology conditions spike, SDG&E performs Public Safety Power Shutoffs to cut wildfire risk. And when they do, they're required by the California Public Utility Commission to notify every affected customer, track confirmation responses, and report the numbers at each stage of the event.
Their existing system wasn't built for this. Motorola Solutions' VESTA platform handled the mass communications, but it could only send messages to 5,000 customers per batch. The notification protocol was a 37-step process that lived entirely in one employee's head, with zero documentation. Commercial customers sometimes got 30 duplicate calls for a single shutoff event. Reports froze the entire dashboard while they generated.
We extended and modernized their VESTA platform: five custom microservices, eight legacy system integrations, an intuitive new UI, and a deployment architecture that runs entirely on-premise in SDG&E's regulated environment. The 37 steps became three clicks. The 5,000-customer ceiling became 150,000+.
New wildfire regulations. An antiquated notification process. And 3.7 million people counting on it.
After the devastating 2018 California fire season, the rules changed. The California Public Utility Commission and Office of Emergency Services imposed new regulations requiring utility providers to track and report customer notifications at every stage of an emergency event. SDG&E's manual systems weren't going to cut it.
The existing notification protocol was, to put it gently, precarious. One employee knew the entire 37-step process. Not a team. Not a department. One person. If they were sick the day a wildfire threatened San Diego County, there was no documented fallback. The VESTA platform, which handled the actual message delivery, could only push notifications to 5,000 customers per batch. For a utility serving millions, that meant manually batching and re-batching until everyone was reached.
It got worse. Commercial customers with multiple cellular towers on a single grid device might receive 30 duplicate phone calls during a single event. Reports took so long to generate that the dashboard froze; operators couldn't do anything else while waiting. And now the state wanted real-time metrics on how many customers had been contacted and what percentage confirmed receipt. The gap between what regulators demanded and what the system could deliver was enormous.
Three days on-site. Five microservices. Eight integrations. Zero cloud.
SDG&E didn't need a new notification platform. They needed their existing one to actually work at the scale and speed that California's wildfire regulations demanded. We extended Motorola Solutions' VESTA platform with custom software that integrated deeply into SDG&E's on-premise infrastructure.
On-site discovery in San Diego
We spent three days at SDG&E's operations center before writing a single line of code. The goal: understand the full 37-step notification process, interview the operators who lived inside it, and map every integration point between VESTA and SDG&E's legacy systems. The process that "lived in one person's head" got documented, diagrammed, and dissected.
What we found went beyond a process problem. The data itself was messy. Customer records, grid device data, meteorology feeds, and reporting databases all sat in separate silos with inconsistent formats. The notification workflow touched eight different services, and none of them talked to each other cleanly.
Microservices architecture for on-premise deployment
SDG&E operates in a highly regulated environment. Cloud deployment wasn't an option. Everything had to run on their own servers, integrated with their own Oracle enterprise databases, behind their own security perimeter. That constraint shaped the entire architecture.
We designed five independent microservice applications that communicate with each other and integrate with eight existing services on SDG&E's server system. Docker containerization made on-premise deployment reproducible and maintainable. Each microservice handles a specific concern: event management, notification orchestration, report generation, customer data synchronization, and the VESTA bridge layer.
Building on VESTA, not replacing it
Motorola Solutions' VESTA platform already handled the core mass communication mechanics: sending emails, phone calls, and text messages at scale. Replacing it would have been expensive, risky, and unnecessary. Instead, we built a custom application layer on top of VESTA using Motorola's COBALT design system, creating a unified dashboard that makes the underlying complexity invisible to operators.
The front-end uses Angular and TypeScript. The back-end runs on Ruby on Rails for the primary API with Sinatra handling the lightweight microservice endpoints. Asynchronous background processing means reports generate without freezing the dashboard; operators can keep working while data crunches in the background.
Meeting CPUC compliance in production
California's Public Utility Commission doesn't just want notifications sent. They want proof: how many customers were contacted at each event stage, what percentage confirmed receipt, and full post-event reporting. We built compliance reporting directly into the notification workflow so that every activation automatically generates the data CPUC requires.
We also eliminated the duplicate notification problem. The old system might call one commercial customer 30 times for a single event because it counted cellular towers rather than unique contacts. The new system deduplicates at the data layer, so the right number of calls go out and reporting accuracy improves automatically.
Microservices architecture
Five custom MiT microservices sit between the operator dashboard and the underlying systems — Motorola's VESTA core handles delivery, eight SDG&E legacy services supply customer, grid, weather, and compliance data. Everything runs in Docker on-premise, behind SDG&E's regulated security perimeter.
Three clicks above water. Five microservices and eight integrations below.
An iceberg is the right analogy for this project. What operators see is dead simple: create an event, select affected customers, and send. Three clicks. What's underneath is a sophisticated data and integration architecture working across SDG&E's entire server ecosystem.
A dashboard built for emergencies
Using Motorola's COBALT design system, we created an interface where operators can see everything that matters at a glance. The event header shows the current state. Rollup data displays key metrics. An at-risk filter lets operators drill into specific customer segments. The device table shows every affected grid device with filtering by multiple criteria. No clicking through five screens to assemble a picture. It's all right there.
From 37 steps to a documented workflow
We didn't just automate the old 37-step process. We redesigned it. The notification and reporting workflow went from 37 undocumented steps (that one person knew) to 10 documented steps, with the operator-facing experience compressed to three clicks for sending a message. Every step is standardized, documented, and person-agnostic. If someone's out sick on the day a wildfire event hits, anyone on the team can run the process.
Reports that don't freeze the dashboard
Under the old system, generating a compliance report meant the entire application locked up. No other work could happen while the data crunched. We built asynchronous background processing so reports generate in the background while operators continue managing the active event. During an emergency, every minute matters. Waiting for a loading spinner isn't acceptable.
The competitor was fined 417 times more. That's not a typo.
SDG&E's rebuilt notification platform is in production, handling Public Safety Power Shutoffs across one of the largest utility service areas in California. Here's what the numbers look like.
That 417x fine comparison deserves context. In 2022, SDG&E's closest competitor in the California utility space was charged 417 times the fine amounts that SDG&E incurred. The difference? SDG&E could demonstrate compliance with the latest reporting regulations because the software was built to generate exactly what the CPUC required, automatically, at every stage of an event.
The broader impact goes beyond fines. The 37-step process that lived in one person's head is now a documented, standardized workflow that any trained operator can execute. New employees get productive in days, not months. The duplicate notification problem is gone; commercial customers get one call, not thirty. And the asynchronous report generation means operators can actually manage emergencies instead of watching loading spinners during the moments when speed matters most.