Build storm outage control tower with ToolJet MCP when a utility control room needs a single app for storm response. The app that comes out is a structured ToolJet application, with data, queries, and interface kept together so the team keeps running it after generation. Controllers use the same app to keep operational decisions and public communication aligned while the storm is active. You get a control-room workflow that turns live utility data into one place the team can keep using. This walkthrough shows the app, the prompt, and the build shape you can reproduce.
Live Map: ranked outages, live map, and crew/ETA assignment panel
Crew View: each crew's current job and queue
Public Messages: auto-generated status text with Duty Manager approval
The main view pairs a ranked outage table with the map, so the controller moves from priority score to geography without changing context. Selecting a row opens the outage detail panel, where customer counts, linked priority sites, the assigned crew, and the restoration ETA stay visible while the controller updates the assignment. If the ETA slips into the warning window, the panel asks for a revised time and a short reason, and the original estimate remains visible for comparison. The crew view filters to current and queued jobs, and the public messages page turns the current ETA into approval-ready text.
Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.
The build took several passes while the layout and data model settled into place. The requirements are consolidated into one prompt you can use from the start to reproduce the app in a single shot.
Build a control-room app called Storm Outage Control Tower in ToolJet for an electricity distribution utility.
Keep three pages: Live Map, which ranks outages, shows them on a map, and lets controllers assign crews and set restoration ETAs; Crew View, which shows each crew's current work and next jobs; and Public Messages, which turns the controller's ETA into a public status update that must pass Duty Manager approval before publishing.
Use a dark control-room look with strong status colours, very large customer-off numbers, and only native ToolJet components. Keep the outage table narrow and put navigation on top.
Use PostgreSQL and four related tables: om_crews, om_outages, om_priority_sites, and om_public_messages. Rank outages with a defensible score built from customers off, priority sites on the feeder, outage age, and vulnerable customers.
When an ETA is already late or close to late, require a revised time and a short reason, while keeping the original ETA visible. For restored outages, show reported time, crew assigned time, restored time, and customer-minutes lost. Public messages must always be generated from the current ETA, never typed separately, and if the ETA changes after submission the message must be marked stale and resubmitted. Field crew users only see their own assignment, while controllers can see every crew.
ToolJet MCP works through the outage model, pages, components, queries, and the wiring between them, then leaves you with one structured ToolJet application inside ToolJet rather than a codebase to host yourself. Enterprise app building does not stop at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change are part of the job, and the generated app sits on a runtime that carries those where supported. The path stays open, so you can move from AI generation to visual editing and then into code when a case needs it.
One outage detail panel showed the wrong row as selected after a table click. The cause was a stale default selection value that made the row state look truthy after the active row changed, and clearing that default fixed the panel so the detail view matched the clicked outage again.
The app ended up with four tables. om_crews stores the crew roster and current assignment state, om_outages holds outage location, status, ETAs, and customer impact, om_priority_sites records critical sites on a feeder, and om_public_messages keeps each outage's public message and approval state.
| Page | Components | What they cover |
|---|---|---|
| Live Map | 12 | Ranked outage list, live map with outage/crew markers, and a detail panel for crew assignment and ETA management |
| Crew View | 2 | Each crew's current job and queue, filtered server-side to the logged-in crew |
| Public Messages | 9 | Public status message per outage, generated from the live ETA, with Duty Manager approval before publishing |
| Metric | Result |
|---|---|
| Pages | 3 |
| ToolJet DB tables | 4 |
| Queries | 11 |
| Components | 23 |
| Code files to maintain | 0 |
| Repair cycles | 1 |
| Final validation | 0 errors |
Electricity distribution network operators and other utility control rooms (water, gas) running storm or multi-outage response, plus telecoms and other regulated infrastructure operators who owe customers a defensible restoration-priority order and a regulator-facing post-event summary.
Controllers get full write access - assigning crews, setting and revising ETAs. Field crews only see their own current and queued jobs, enforced server-side by matching the logged-in user's email against the crew record, not by a client-side filter. Public messages require a Duty Manager's explicit approval, recorded by name, before they can be published - controllers can draft and submit but not publish directly.
Outage locations, crew assignments, and public ETA text move through this app. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.
ToolJet Workflows adds the notification layer. When a controller submits a public message for approval, a workflow posts the update to Slack, emails the duty manager through Gmail, and writes the approval state back to om_public_messages.
This build shows a storm outage control tower that ranks outages, ties map context to crew dispatch, and keeps public messages locked to the controller's current ETA. The output is a structured ToolJet application, so once generation finishes you keep working in the same app instead of inheriting a disposable screen or a separate codebase. That matters because the visual editor covers the routine changes, code stays available for edge cases, and the runtime keeps the data, workflows, and governance in one place where supported, which is the shape you want when the process changes during a storm.
You can easily build a 4-page app with ToolJet MCP for as little as $0.17 with a lean model (Luna medium), or pay more for the latest flagship reasoning (Sol) if that's what you're after. The cost is your call, not a floor we set for you.
| Model | Credits | Minutes | Notes |
|---|---|---|---|
| Astra | 290 to 550 | 13 to 16 | The most polished pages, when cost matters less |
| Sol (Recommended) | 300 to 650 | 14 to 22 | The best balance of quality and cost for most apps |
| Terra | 85 to 210 | 5 to 12 | The fastest, and best kept to smaller apps |
| Luna max | 35 to 55 | 33 to 62 | The most complete Luna, and by far the slowest |
| Luna high | 25 to 50 | 22 to 41 | Mid-effort Luna, between medium and max |
| Luna medium | 10 to 30 | 14 to 20 | A quick first draft or a small tool |
Three to four builds per model across four-page apps. 1 credit = 1 cent. Credits and time are estimates only and will vary with the complexity of what you ask for. This measures cost and speed only, not how complete or polished the result is.
Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.
Build storm outage control tower with ToolJet MCP from your own outage data, then request a ToolJet demo.
The prompt in this article lets you build storm outage control tower with ToolJet MCP as a structured ToolJet application, not a loose screen mockup. The outage model, crew dispatch, and public message flow stay connected to the same data and page logic, so the app keeps its shape after generation.
The live map ranks outages and shows where they sit, the crew view shows current and queued work for each team, and the public messages page turns the current ETA into a publishable update. The three views share the same outage records, so a controller does not re-enter the same facts.
No code is required for the common edits in this build, because the layout, data wiring, and message flow are already in the app. You can change the map, tables, and text in the visual editor, then drop into code only when a special case needs it, which keeps the routine changes fast to adjust.
Yes, the app is built on PostgreSQL, so you can point it at your own outage records and keep the same control-room flow. The ranked view, crew assignment, and public messages page all work from the same source of truth, which makes the existing database the starting point instead of a rewrite.
You keep a structured ToolJet application, and the runtime keeps carrying the data and workflow pieces where supported. Later changes happen in the same app instead of handing your team a code bundle to own and reassemble again.
Use the consolidated prompt in this article to describe the three pages, the four tables, and the rule that public messages always follow the controller's ETA. The prompt lets you start from the same requirements and get the same control-room shape in one pass. Yes, the app stays a shared ToolJet artifact, so teams can work against one outage model instead of copying exports around. That helps a controller, a builder, and a reviewer stay aligned when the table, map, or message flow changes.