This map supports the outage work order verification guide. It is for consultants who need to tell a client's operations director which joins matter before anyone discusses records.
Five systems behind one restoration
A utility's restoration history rarely sits in one product. A typical mid-sized distribution utility spreads it across:
- Call platform or IVR, where customers report the outage and the call gets an ID.
- Outage platform, which groups calls into events, predicts the failed device, assigns crews and records restoration steps.
- Asset or work management system, where the work order and the repaired asset live.
- Meter data system, which may record power-off and power-on events by meter.
- Callback log, a module, spreadsheet or call center list showing who was rung back and what they said.
Some outage platforms can model restoration as related events rather than single tickets. Oracle's Network Management System user guide has sections on related partial restoration events, updating multiple events and completing an event. How a given utility configured those features, and what its asset system stores against each work order, varies by product, version and implementation, so every row below is a question for the administrator, not an assumption.
OracleThe map: which system holds what, and the key that joins it
| System | Record it holds | Linking key to the next system | Usual owner |
|---|---|---|---|
| Call platform | Trouble call with time and premise | Call ID carried onto the outage event | Member or customer services manager |
| Outage platform | Event, predicted and confirmed device, crew assignment, restored time per step | Event ID written onto the work order | Operations director |
| Outage platform | Nested or partial restoration event | Parent event ID on the child event | Operations director |
| Asset or work management system | Work order, asset worked, completion time | Work order number and asset ID | Asset management lead |
| Meter data system | Power-off and power-on events | Meter or premise ID plus timestamp | Metering manager |
| Callback log | Customer confirmations after restoration | Event ID and premise | Control room supervisor |
Two keys carry most of the weight. The event ID on the work order joins field action to the outage, and the parent event ID joins a correction to the closure it overturned. If either is missing, the history still exists, but it no longer tells one story.
One fully joined case (Illustrative)
A fictional case, invented for this page, for a 470-person electric and water utility. Identifiers are placeholders, not real formats.
| Step | System | What the record says | Key used to join |
|---|---|---|---|
| Report | Call platform | 14 calls from one rural road after a wind gust | Call IDs attached to event 1 |
| Event | Outage platform | Recloser predicted locked out; 120 customers | Event 1 |
| Work order | Asset system | Reset recloser; asset recorded as the recloser | Event 1 on work order A |
| Closure | Outage platform and asset system | Recloser reset; event 1 marked restored | Work order A completion time |
| Check | Meter data system | 112 meters report power-on; 8 report none | Meter IDs on event 1 premises |
| Nested event | Outage platform | Child event for 8 customers, broken service drop | Parent event 1 on event 2 |
| Second order | Asset system | Repair service drop | Event 2 on work order B |
| Verified | Callback log | All 8 confirmed back | Event 2 and premises |
Read across the last column. Every hop used a different key, and the case only reads as one restoration because each key was stored. The worked exception case walks a similar sequence step by step from the decision-makers' side.
Where the joins fail after migrations and handovers
| Link | What breaks it | What the history looks like afterwards |
|---|---|---|
| Call ID to event | Calls archived separately from events | Events with customer counts but no reports |
| Event ID on work order | Work orders created by hand during storms | Field work that cannot be tied to an outage |
| Asset ID | Predicted device never corrected to confirmed device | The wrong asset appears to have failed |
| Parent event ID | Child events migrated as stand-alone outages | Two unrelated outages instead of one correction |
| Meter ID and time | Meter events purged on a short retention rule | Restoration checks acted on but unprovable |
The industry treats these hand-offs as interfaces in their own right. IEC 61968-1 sets out an interface reference model for exchanging information between distribution management functions, naming outage management, work management, network model management and metering among them. A utility that integrated its systems along those lines is more likely to have kept keys at each hop; one that relied on manual re-keying during storms is more likely to have gaps. Either way, the administrator's answers, not the standard, say what exists.
Questions for the outage platform administrator
Ask in one conversation and record only the answers:
- Does each work order carry the outage event ID, and since what year?
- Are nested or partial restoration events linked to their parent, and does the link survive export?
- Is the confirmed device stored separately from the predicted one?
- How long are meter power-on events retained, and can they be matched to events?
- Are callbacks logged in a system, or only worked from a list?
Partners never ask for exports, data dictionaries or logins. Note quality is a separate question, covered in assessing field service records and resolution notes; the wider category is on field service histories, and why cross-system data carries more value explains why the joins matter to AI labs and data users at all. The asset-side migration risk is covered in CMMS migration.
Who owns the joins, and qualification
Each system has its own administrator, and none of them decides on licensing. The operations director convenes; the CEO or general manager decides, with counsel. When the map is filled in, carry the answers into the outage verification referral brief.
The utility needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license 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: demand for joined restoration histories, the rights result for customer-linked and network fields, the preparation required and any offer. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application.
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 the administrator confirms that event IDs reach the work orders and nested events keep their parent, register as a partner, check the utility on who qualifies and read the program terms before you introduce the operations director.