When a NetSuite2.com Connect query returns fewer rows after migration, isolate permission scope, schema mapping and query semantics before changing access or accepting the new total. A connection that succeeds proves authentication and basic connectivity, not parity with an earlier reporting population.
The old NetSuite.com data source is unavailable after the account's 2026.1 upgrade. Investigation should therefore use retained, authorized legacy evidence and the current NetSuite2.com source. Do not build a recovery plan that depends on restoring the retired source as an ordinary reporting option.
Select one consequential output and identify the lost business facts. Are entire transactions absent, individual fields blank, custom records unavailable, or amounts different despite matching identities? Each symptom points to a different investigation.
Record the last accepted output, its generation time, account environment, role, query version and scope. A production comparison against a sandbox extract can create a false migration defect. So can a legacy file captured before later transactions were entered.
Where old evidence is incomplete, state that limitation. The objective becomes validating the current required population against authoritative records, rather than claiming exact parity with an unavailable historical result.
NetSuite2.com uses role-based access. Enabled features and the assigned role's permissions determine the accessible data. The Static Data Model can expose schema structure and names while still restricting the rows the role is allowed to retrieve.
Seeing a table or column in metadata therefore does not establish permission to its contents. Conversely, a missing familiar table name can reflect a schema change rather than a lost business capability. Inspect the current record and field definitions through supported discovery tools.
Do not respond by assigning a broad administrator or data-warehouse role merely to make a comparison pass. First establish the required approved population, then ask the security owner to evaluate any access change. Preserve evidence of both intended inclusions and intended exclusions.
The NetSuite2.com schema differs from the retired source. Some records and fields map differently, some values have different meanings, and the published mapping is not an exhaustive guarantee of equivalence.
For each consequential legacy field, document the business meaning, current candidate source, data type, allowed values and known limitations. A renamed column is a straightforward case; a field split across related records requires more design.
Check enumeration values and null treatment. A filter copied from an old schema may select no rows if it compares a label with a code. An inner join to a newly modeled optional relationship can also remove otherwise valid transactions.
Keep custom fields separate from standard-field mapping. Confirm their actual IDs and accessibility in the target account. Similar display labels are not sufficient evidence that the pipeline is reading the same field.
A retained legacy extract contains 12,000 eligible transaction identities. A first NetSuite2.com query returns 10,800. Investigation establishes that 700 of the missing identities belong to a subsidiary outside the new role's approved scope, 300 fail a migrated status predicate and 200 have no match in an optional related table used by the query.
The arithmetic is 700 + 300 + 200 = 1,200 missing identities. The causes require different decisions. Security must determine whether the 700 should be accessible to this reporting purpose. The query owner can correct the 300-record predicate after validating current status semantics. The 200-record relationship needs a design that preserves the intended base population.
If the 700 are intentionally outside scope, the accepted current report should not be forced to reach 12,000. Its comparable target becomes 11,300 after the approved query corrections, with the scope difference documented.
These are hypothetical populations. The example shows why a single missing-row total cannot determine whether the solution is a permission change, query correction or better labeling.
| Step | Test | Evidence to save |
|---|---|---|
| 1 | Confirm account, environment and current data source | Redacted connection identity |
| 2 | Query a known authorized base record | Source identity and observed result |
| 3 | Remove optional joins in a diagnostic copy | Base identity count |
| 4 | Reapply predicates individually | Identities removed by each predicate |
| 5 | Add mapped fields and joins one at a time | First point of omission or multiplication |
| 6 | Test the production extraction role | Approved visible and excluded samples |
| 7 | Compare the complete target output | Identity and amount reconciliation |
Use read-only diagnostics and protect the production job's definition. A fast exploratory fix can create a second, undocumented query that someone later mistakes for the approved version.
An amount can change because rows are missing, because the measure changed, or because conversion and sign conventions changed. Establish the population first, then compare monetary fields at the intended grain.
Retain the source currency, subsidiary, book and date or period context. A new schema field that represents transaction currency is not interchangeable with an old base-currency field merely because both are called amount in the destination.
Inspect duplicate identities as well as missing ones. A migration can omit one subsidiary while multiplying another through a join, leaving the grand total deceptively close. Reconcile by business dimensions that expose those offsetting effects.
If a legacy query contained undocumented assumptions, do not preserve them automatically for numerical parity. Ask the report owner whether the old output represented the intended business definition. The accepted migration may need an explained correction rather than a perfect reproduction of an earlier defect.
A developer's successful desktop query can use a different role or connection definition from the scheduled integration. Compare effective account, data source, role, driver configuration and query parameters without copying credentials into the investigation pack.
The Connect login audit can help an authorized administrator identify relevant connection usage, including data source and client details. Its availability and required permission should be verified in the account. Use it as diagnostic evidence rather than assuming a familiar job name proves which connection ran.
Also inspect destination transformations. A renamed column, changed data type or null value may cause rows to be rejected after Connect successfully returns them. Count source rows read separately from destination rows accepted.
Keep the comparison focused on the exact route. Connect's metadata and role behavior should not be diagnosed by assuming that a SuiteScript option with a similar name has the same effect.
For each important report, record whether the outcome is equivalent, intentionally changed, corrected from a legacy defect or still unresolved. Include the accepted population, field mapping, control totals and known exclusions.
Require a named owner for unresolved data gaps. “The new source is different” is not a sufficient explanation for a missing financial population, but neither is “the totals must match” a sufficient reason to broaden access.
For a focused investigation, provide the current query, redacted connection context and identity bridge to CuriousRubik's NetSuite integration services. Keep permission approval and financial acceptance with their responsible owners.
No. It confirms basic connectivity, while role restrictions, schema changes, query predicates and destination processing can still omit required data. Validate known source identities and the approved population.
No. It exposes schema structure and names while role-based data restrictions still apply. Metadata visibility should not be interpreted as authorization to retrieve the corresponding rows or fields.
The retired source is unavailable after that upgrade. Use retained authorized legacy evidence and validate the current NetSuite2.com implementation. Do not depend on the old source as the normal recovery route.
Only when both represent the same intended population at a comparable point in time. Document approved scope changes and legacy defects rather than forcing parity through inappropriate permissions or filters.
Choose one known authorized missing record, query its base population without optional joins, and reintroduce predicates and related fields individually. This identifies the first exclusion point before a broad redesign or access change.