When NetSuite rolls out a major release, most attention goes to the headline features. AI dashboards, consignment inventory, and new pricing engines. But buried inside the 2026.1 release is a quieter, more disruptive change that has already broken production integrations for teams who weren't watching for it.
The change is to how NetSuite handles address subrecords specifically, the enforcement of parent-record filtering across queries, APIs, and SuiteQL. If your integration pulls customer or vendor addresses, there's a good chance it needs updating right now.
| 3 integration layers affected SuiteQL, SuiteScript, REST API | 0 schema or permission changes same data, new access model | Apr production rollout window completing by the end of April 2026 |
What actually changed
NetSuite pre-announced this in the community back in December 2025, but it's easy to have missed. The core change: address subrecords are now filtered to only return addresses associated with the parent record in context.
Before 2026.1, a SuiteQL query joining on address tables could pull back address data across records, it was loosely associated. After 2026.1, NetSuite strictly enforces that only addresses belonging to the entity you're querying are returned.
"Queries and APIs that read address information will show only the addresses related to the primary record you're viewing — such as a specific customer, vendor, or employee."
As a side effect of this stricter enforcement, the underlying table structure for address data was also reorganised. What used to be accessible through a single join is now split into two separate entity-scoped tables. This is where integration starts breaking.
The old join vs the new join
If your integration uses SuiteQL to retrieve customer billing addresses, you were likely using a pattern like this:
BEFORE 2026.1
LEFT JOIN
CompanyAddressbookEntityAddress CA
ON C.defaultbillingaddress
= CA.nkeyAFTER 2026.1
JOIN CustomerAddressbook CAB
ON C.id = CAB.entity
JOIN CustomerAddressBookEntityAddress CABEA
ON CAB.addressbookaddress
= CABEA.nkeyThe old CompanyAddressbookEntityAddress table was removed in 2026.1. Queries referencing it return an INVALID_PARAMETER error: "Record 'CompanyAddressbookEntityAddress' was not found."
The replacement pattern requires two joins: first, through CustomerAddressbook to link the customer to their address book entries, and then through CustomerAddressBookEntityAddress to retrieve the actual address fields.
Why NetSuite made this change
The stated rationale is data accuracy and privacy. Previously, the address subrecord model allowed for cross-entity visibility address data wasn't always strictly scoped to its parent record. This could result in address information surfacing in contexts where it didn't belong, both cluttering results and creating potential compliance exposure.
By splitting the table into entity-specific structures and enforcing parent-record filtering at the query level, NetSuite ensures that when you retrieve a customer's addresses, you only ever get that customer's addresses; nothing bleeds across records.
It's a sound architectural decision. But the rollout has caught teams off guard, especially those running automated integrations with no human in the loop to notice the failure.
Case study: a production integration goes dark
The following is a real incident that played out the morning of the 2026.1 upgrade, an example of how this address change surfaces in practice.
Integration fails on customer query
During routine monitoring, the Salesforce–NetSuite sync for customer account data returns errors. The SuiteQL query powering the sync, which joins on CompanyAddressbookEntityAddress to retrieve billing address fields, throws an INVALID_PARAMETER error. The integration is paused to prevent cascading failures.
Root cause traced to 2026.1 release
Updated join tested in Postman and sandbox
The query is rewritten to use the two-table join pattern through CustomerAddressbook and then CustomerAddressBookEntityAddress. The updated query is validated in Postman, then deployed to the sandbox, where several scenarios are tested successfully.
Fix approved and deployed to production
With sandbox validation confirmed, the team receives approval to deploy to production. The fix goes live the same day, the integration resumes, and account sync returns to normal operation. Total downtime: one business morning.
The fix itself was straightforward: two joins instead of one, different table names. The cost came from the time taken to diagnose an unexpected production failure during business hours. Teams with a Release Preview testing process, or who had reviewed the December 2025 community notice, would have caught this in the sandbox before go-live.
What you should do now
✓ Audit any SuiteQL queries that reference CompanyAddressbookEntityAddress or similar company-scoped address tables and update them to the two-table entity-specific join pattern.
✓ Review integrations that use SuiteScript 2.0/2.1 or the REST API to read address subrecords. The filtering change affects all three layers, not just SuiteQL.
✓ Run your updated queries in the Release Preview or sandbox environment before your production account is upgraded, if it hasn't been already.
✓ Add address-related queries to your integration health check routine so failures surface through monitoring rather than user reports.
The 2026.1 address change isn't a bug; it's a deliberate architectural improvement. But like many well-intentioned platform changes, it has a real blast radius for teams running integrations that assumed the old data model. The fix is simple. The preparation is what makes the difference between a five-minute sandbox update and a lost morning in production.
