Verification is the step that separates "the crew closed the job" from "every customer on that circuit had power again." The two can differ, which is why a utility's history of checked restorations is worth knowing about before its platform changes.
What should be inventoried before an outage system migration affects outage work order verification history?
Five record classes across at least two systems, and the dates that bound them. The particular risk is that the new outage platform imports the network model and open events, while closed events, their partial restorations and the links to work orders in the asset system stay behind.
| Record class | Typical system | Ask about | Why it matters for verification |
|---|---|---|---|
| Fault reports and trouble calls | Outage platform, call center or IVR | Years kept; whether calls stay linked to events | Shows who reported what, and when |
| Event history with predicted device | Outage platform | Whether closed events migrate with their history | Shows what the system thought had failed |
| Crew actions and work orders | Outage platform and asset or work management system | How the two are linked; who closes the work order | Shows what the crew did and when they called it done |
| Restoration checks | Callback logs, meter event data, field notes | Whether checks are stored or only acted on | Shows whether every customer was actually back |
| Partial restoration and nested event links | Outage platform | Whether parent and child events keep their relationship | Shows what a single closure hid |
Ask the operations director, at metadata level only:
- How many years of closed outage events does the current platform hold, and how far back do work order links go in the asset system?
- Will the migration bring over closed events with their partial restoration history, or summary records only?
- Are callbacks and meter event data retained after an event closes, and for how long?
- Who closes a work order: the crew, the dispatcher or the system on restoration?
- Are any verification steps recorded only in radio logs, spreadsheets or crew notes?
- When does read access to the old platform end?
Partners collect answers, never exports, network maps or logins, and never recommend keeping data the company has no authority to keep. The asset side of a similar migration is covered in CMMS migration.
Why closed events are the history most at risk
An outage platform exists to manage the next storm. Its migration is judged by whether the network model is right and open events carry over cleanly on cutover night. Closed events are a reporting concern, and reporting is usually handled by a summary extract.
The structure of the history is what a summary loses. Outage management systems model restoration as a set of related events, not one ticket: Oracle's Network Management System user guide, for example, has procedures for copying event details to related partial restoration events, updating multiple events and completing an event. When those relationships are flattened, a single "restored" timestamp replaces the record of which customers came back when.
OracleThat matters beyond any data discussion. Utilities report reliability through indices built from interruption history. Form EIA-861 asks for SAIDI and SAIFI both including and excluding major events, counts sustained interruptions of over 5 minutes, and records SAIDI in minutes. Under the IEEE 1366 method, a major event day is one whose daily SAIDI exceeds a threshold, so storms can be studied separately from normal operation. The figures a utility filed in past years were computed from event records like these, which is one reason the operations team may already care how the history migrates.
An illustrative inventory sheet
Illustrative only; the utility and figures are fictional. A 520-person electric distribution cooperative is replacing its outage platform before next storm season. The operations director fills in the sheet from the project plan in one meeting, without opening any event.
| Record class | System | Years held | Owner | Moves at cutover? | Readable until |
|---|---|---|---|---|---|
| Trouble calls | IVR and call center platform | 2016 to now | Member services manager | Not affected | Call platform kept |
| Event history | Outage platform | 2014 to now | Operations director | Open events only | Old platform license end |
| Partial restoration links | Outage platform | 2014 to now | Operations director | No | Old platform license end |
| Work orders | Work management system | 2012 to now | Asset management lead | Not affected | Work system kept |
| Callbacks and meter checks | Outage platform, meter data system | 2018 to now | Operations director, metering | Summary only | Meter data retention rule |
Reading the sheet: calls and work orders are safe because those systems stay. The event relationships, which are what show a closure that hid customers still out, depend on the old platform license, and that date belongs in the handoff.
Which date is the real deadline?
The day read access to the old outage platform ends, from the license or the decommission plan, not the cutover night. Some projects keep the old system readable for a period after cutover so results can be compared; ask whether that is planned and for how long. Add the retention rule for meter event data, which may be shorter than either. If no date is fixed, record "not set" rather than guessing.
Who decides, and does the company qualify?
The operations director knows coverage. The CEO, COO or general manager decides whether a licensing discussion fits, and counsel checks contractor agreements, customer data and any limits on sharing network information. For a cooperative, the board may also need to be informed.
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.
What stays unknown until SourceX reviews it: dataset demand for this record type, the rights review result, what must be removed or de-identified, and whether any offer follows. Partners sign the Channel Partner Agreement before submitting introductions, and the first valid introduction within the 90-day window is credited when the company submits a verified application. Related sectors are on energy and utilities and the industries hub.
Go deeper on outage work order verification
- Outage work order verification exception examples: one restoration that closed too early, worked through step by step.
- Outage work order verification records across systems: a system map of the identifiers that join calls, events, work orders and meter checks.
- Who can license outage work order verification records: a decision tree for which executive to introduce and what needs counsel.
- Outage work order verification referral brief template: a fill-in, metadata-only brief for the introduction.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a client's outage platform migration could leave years of verified restorations and nested events behind, register as a partner, check the company against who qualifies, and read the program terms before you send the handoff.