Version: eXtendFiles all versions
Overview
eXtendFiles records are typically child records of the record they are uploaded to — an invoice, a case, a customer, a custom record, and so on. Because the relationship is a standard NetSuite parent/child link, you can build a saved search from either side of it:
- An eXtendFiles saved search that joins up to the parent record.
- A parent record saved search (for example, Transaction filtered to Invoice) that joins down to eXtendFiles.
Both return the same underlying records, but they behave differently in terms of which fields are available, how many rows you get back, and how easy the search is to build. This article explains how to choose, and covers the extra step required on shared record types such as Transaction.
A common use case: returning the associated files or file URLs of every eXtendFiles record attached to a set of invoices.
How the parent/child relationship works
The eXtendFiles record has a separate parent record link field for each record type it is enabled on.
| Direction | What each row represents | Fields available |
|---|---|---|
| eXtendFiles → parent | One row per file | All eXtendFiles fields, plus body/header fields of the parent |
| Parent → eXtendFiles | One row per parent record, per matching file | All parent fields (including line-level), plus eXtendFiles fields |
Two behaviors to keep in mind:
- Row multiplication. On a parent-side search, an invoice with four files returns four rows. If the search also returns transaction lines, the rows multiply again. Add a Main Line is true criterion to keep the search at one row per file.
- Records with no files. A parent-side search returns invoices whether or not they have files, with blank file columns. Add a criterion such as eXtendFiles : Internal ID is not empty to exclude them. An eXtendFiles-side search never returns empty rows, because every row starts from an existing file.
Choosing which side to build from
The deciding factor is almost always whether you need line-level data.
| If you need… | Build from |
|---|---|
| Item, quantity, rate, line amount, line-level classification, or transaction column fields | Parent |
| Body-level parent fields only — date, customer, status, total amount, subsidiary, body custom fields | eXtendFiles |
| Criteria on file attributes — file type, upload date, approval status, custom attributes | eXtendFiles (simpler either way) |
| A single clean list of file URLs | eXtendFiles |
A parent join from a custom record exposes the parent's body/header fields only. NetSuite does not surface transaction line columns through that join, so line-level criteria and results are only possible from a Transaction-based or custom transaction-based search.
Option 1: eXtendFiles saved search (recommended when it fits)
Use this when your criteria are body-level. It is faster to build and avoids the shared record type issue described in Option 2.
- Go to Lists → Search → Saved Searches → New and select the eXtendFiles record type.
- On the Criteria subtab, add the join for the parent record type — for invoices, the eXtendFiles - Invoice join — and set the filters you need (date range, customer, status, and so on).
- Because the join itself is specific to invoices, you do not need a separate Type is Invoice criterion.
- On the Results subtab, add your eXtendFiles columns — Name, File Type, URL, Created Date — along with any parent columns you want, such as the invoice number and customer.
- Save and run the search.
Option 2: Parent record saved search joined to eXtendFiles
Use this when you need line-level criteria or results, or when you already have a working transaction search and only want to add file columns to it.
Transaction is a shared record type. Invoice, Sales Order, Purchase Order and every other transaction type share a single Transaction search. Because eXtendFiles has a separate parent link field for each of those transaction types, the Transaction search's join list shows several eXtendFiles entries that all look identical — NetSuite labels each join with the child record name, not the field name, so there is nothing to indicate which one belongs to invoices.
Identifying the correct join
- Open an invoice that you know has at least one eXtendFiles record attached, and note its document number.
- Create a Transaction saved search with criteria Type is Invoice and Number is the invoice from step 1.
- On the Results subtab, add the same field — Internal ID works well — from each of the eXtendFiles joins in the list, one column per join.
- Run the search. Only one column returns a value: that is the invoice link field.
- Remove the other columns, then build out the rest of the search using that join.
Save the finished search and copy it as the starting point for future file-related transaction searches, rather than repeating the identification step each time.
Completing the search
- Add Main Line is true to prevent line rows from multiplying the results, unless you are intentionally reporting at line level.
- Add eXtendFiles : Internal ID is not empty if you only want invoices that actually have files.
- Add the eXtendFiles result columns you need, such as URL and File Type, from the same join you identified.
Record types that are not shared
The ambiguity in Option 2 is specific to NetSuite's shared search types — Transaction, Item, and Entity — where many record types are queried through one search type.
Every other record type has its own search type, so the join list contains exactly one eXtendFiles entry and no identification step is required.
Native non-shared record types (Case, Task, and similar)
- Create a saved search on the record type itself — for example, Case.
- On the Criteria or Results subtab, open the join list and select the single eXtendFiles entry.
- Add fields and filters as normal.
From the eXtendFiles side, the corresponding join is named for that record type — for example, eXtendFiles - Case.
The same rules about row multiplication and empty rows still apply: a case with three files returns three rows, and cases with no files return blank file columns unless filtered out.
Custom record types
Custom records behave the same way as Case and Task. When eXtendFiles is enabled on a custom record type, a dedicated parent link field is created for it.
- From the custom record search, there is one eXtendFiles join.
- From the eXtendFiles search, the join is labeled with the custom record's name.
- Because a custom record has no shared search type and no line-level sublist to reconcile, either direction works. Choose based on whether you want one row per file or one row per custom record.
If the custom record is itself a child of another record, note that NetSuite limits how many joins a single saved search can traverse. You cannot chain from eXtendFiles up through a custom record and on to that record's own parent in one search. Use a workbook or two searches instead.
Notes
- The user running the search needs at least View permission on the eXtendFiles custom record type. Without it, the joins do not appear in the field list.
- The same parent/child logic applies to SuiteAnalytics Workbooks and SuiteQL. In SuiteQL you reference the parent link field directly by its field ID, which removes the guesswork of Option 2 entirely.