The quick answer
A Customer saved search can repeat a Customer ID when its results or criteria join to multiple Contacts or Addresses. Compare the Customer Internal ID with a child identifier on each row. Then decide whether the search needs one row per customer or one row per related record.
The screenshots use fictional people, company names, and Customer data. Counts are from this example; your account's relationships and criteria determine its rows.
Before you start
Use an unsaved Customer search for the diagnosis. You need permission to view its related Contacts and Addresses. Note the business question before changing columns: do you need one row per customer, contact, or address? Keep Internal ID available so names do not have to stand in for identifiers.
01. Preview direct Customer fields
Start on Results > Columns with direct Customer Internal ID and Name/ID. Preview the search and write down the count and IDs. The example shows six rows for six customers. This is the baseline for the later comparisons, not a promise that every Customer search returns one row per customer.
02. Add Contact fields
Return to the definition. Add Contact Fields... > Name and a Contact identifier when available, then preview again. The example rises to seven rows. Customer Internal ID 101 appears twice, paired with Contact IDs 501 and 502. Those rows refer to two contacts associated with one customer. The repeated Customer name is the clue to inspect the join, not proof that a second Customer record exists.
03. Compare Address rows
Add a field through Address Fields... and an address identifier or label. Preview again. In the sample, the result has nine rows: the same Customer and Contact can appear with different Address values. Two independent one-to-many relationships can multiply combinations, subject to criteria and the records actually present. Inspect the field path; a direct default or primary address value is different from joining every Address row.
04. Choose the row grain
Inspect Criteria for related Contact or Address conditions too; a join can affect results even without a visible child column. For one row per customer, use direct Customer fields or a specific primary reference that answers the question. Keep child fields and identifiers when the question is about contacts or addresses. Grouping can produce a customer summary, but it changes what each child-derived value means. Define that aggregation before using Summary Type.
The final diagnostic preview returns to six Customer rows after removing the related columns. The search remains unsaved in this walkthrough.
Common questions
Did NetSuite create duplicate Customer records? Repeated result rows alone do not establish that. Compare Customer Internal IDs first. Different child IDs beside the same Customer ID point to a related-record join.
Can Criteria cause repeats? Yes. A related Contact or Address criterion can introduce a join even when the result columns show only Customer fields. Preview after changing one condition at a time.
Should I group by Customer to hide repeats? Only if a customer-level summary is the actual question. Decide how each child-derived value should aggregate; otherwise grouping can hide useful detail.