This field map belongs to the number porting failure resolution guide. The worked port case follows one rejection day by day; this page is the wiring under any such case: which system keeps which field, which key crosses between systems and who administers each one.
Four systems and the fields each one keeps
A provider typically spreads one failed port over four places. Each answers a different question.
- Order platform: what was asked for, and in which version. Order ID, version number, numbers, old-provider account number, service address as submitted, reject reason codes, firm order commitment date, activation timestamp, submitter and approver.
- Service desk: why someone acted. Ticket number, customer ID, agent summary of the rejection, diagnosis notes, the lead's approval comment, closure code and test-call note.
- Shared mailbox: what arrived outside the platform. Reject notices and copies of the losing provider's customer record received by email. Often the only place that record's reference survives.
- Customer register or CRM: whose numbers they are. Internal customer ID, sites and contacts. It keeps a multi-site customer from splitting into several unrelated IDs.
Business accounts with several lines and sites carry more fields to validate than a single-line account, so they can produce more rejections and more joins worth mapping.
Field map: system, record, linking key and owner
Read across a row to see which key leaves each system, where it should land, and what usually breaks it.
| System | Record | Linking key out | Should land in | Administered by | What breaks it |
|---|---|---|---|---|---|
| Order platform | Port order and its versions | Order ID plus version | Service desk ticket | Provisioning director | Tickets that name only the customer |
| Order platform | Number list | Telephone numbers | Ticket notes | Provisioning director | Partial lists after a split order |
| Order platform | Reject notice | Reason code and received date | Ticket summary | Provisioning director | Rejects handled from the mailbox only |
| Shared mailbox | Losing-provider record copy | Record reference | Ticket diagnosis note | IT | Copies saved on a personal drive |
| Service desk | Approval to resubmit | Approver and comment date | Approver field on the corrected version | Customer care director | Verbal approvals with no note |
| Customer register | Customer and sites | Internal customer ID | Order and ticket | Customer operations | Separate IDs per site |
Two keys are typed by people, not generated: the order ID in the ticket and the losing-provider record reference in the diagnosis note. Ask about those first.
One port joined end to end (Illustrative)
Illustrative and invented for this page. A fictional 260-person business voice provider ports 22 numbers for a regional accounting firm; the losing provider rejects the order because the account number does not match.
| Key | Value | Found in | Joins to |
|---|---|---|---|
| Order ID and version | PO-4471, versions 1 and 2 | Order platform | Ticket SD-55120 |
| Telephone numbers | 22 numbers, one site | Order platform; ticket notes | Same list on both versions |
| Customer ID | C-20931 | Customer register; order; ticket | Account history |
| Reject reason | Account number mismatch, day 2 | Order platform; mailbox copy | Ticket diagnosis |
| Losing-provider record | Shows a sub-account number | Mailbox; ticket note | Corrected version 2 |
| Approver | Provisioning lead, day 3 comment | Ticket; version 2 | Corrected version 2 |
| Outcome | Commitment date day 4, activation day 7 | Order platform; ticket closure | Closed ticket with test-call note |
Read top to bottom: the same 22 numbers moved under one customer, version 1 failed for a stated reason, the losing provider's record showed why, a named lead approved a corrected version 2, and the activation closed the ticket. Remove the version number and version 1 vanishes; remove the order ID from the ticket and the diagnosis floats free of the order it explains.
Versions and timestamps: what a cutover can erase
The column most at risk in a provisioning migration is the one holding history. Some order platforms keep each correction as a new version; others overwrite the submitted values when a correction goes in. If the new system imports only the current state of each order, the rejected value disappears and the chain loses its "before". A consultant can flag that risk from the data model without opening an order.
Timestamps need a check too. The NPAC is made up of seven regional systems handling portability for wireline, wireless and VoIP providers, and access is limited to authorized users for permitted purposes. So the company's own activation timestamps, not a pull from the NPAC, are what belong in an inventory. Ask which time zone each system records, since a ticket closed "before" activation may turn out to be after it. The general case for joining records across systems is set out in why cross-system data has more value, and CI build failure logs are a comparable failure-and-fix record from another field.
Join questions for the provisioning director
One question per key, answered from configuration knowledge:
- Order to ticket. "Do agents paste the order ID and version into the ticket?"
- Versions. "Does the platform keep each correction as a version, and will the migration import them?"
- Mailbox to ticket. "Are emailed rejects and losing-provider records attached to the ticket, or left in the mailbox?"
- Approval. "Is the approver recorded on the corrected order, the ticket, or neither?"
- Customer. "Does a multi-site customer have one ID across orders and tickets?"
Port orders carry customer account details, and carriers have a duty under Section 222 of the Communications Act to protect customer proprietary network information, so record answers as metadata only: years, rough counts, systems, owners. Who can authorize a discussion is covered on who can license number porting failure records. The introduced company needs 50+ full-time employees at peak (contractors excluded), a 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. Whether records received from other providers can be licensed stays unknown until SourceX's rights review. Neighboring record types are on the telecommunications page.
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 provisioning director confirms that versions survive and tickets carry order IDs, register as a partner, check the provider against who qualifies, and read the program terms before you make the introduction.