A NetSuite view-only pricing sublist gives users access to item pricing information directly from a custom record without allowing them to edit pricing lines. The most reliable approach is to store pricing rows in a related custom record, connect each row to the parent record with a List/Record field, and display those rows through a saved search configured as a custom sublist. Because search-based custom sublists are read-only, users can review item, currency, quantity break, price level, and effective-date data without changing the underlying pricing records.
This design separates pricing maintenance from pricing visibility. Pricing administrators update the related records through controlled forms, workflows, imports, or SuiteScript, while sales and operations users see an accurate pricing view from the main custom record. The key implementation decisions are the relationship field, saved search criteria, sublist columns, form placement, and permissions.
What a NetSuite view-only pricing sublist actually does
A view-only pricing sublist displays related pricing records on a parent custom record. It does not copy pricing data into the parent record, and it does not create a second editable pricing interface.
For example, a custom record representing a customer agreement might display related pricing rows containing:
Item
Item description
Price level
Currency
Minimum quantity
Unit price
Effective date
Expiration date
Approval status
The pricing rows remain separate records. The sublist simply presents records that meet the relationship and search criteria.
This distinction matters because a custom sublist based on a saved search is not the same as an editable transaction sublist. A transaction item sublist supports line editing through the native transaction form and SuiteScript line APIs. A search-based custom sublist is intended for related-record visibility. It provides a controlled read-only view, not a replacement for a native transaction sublist.
For the broader process of identifying internal IDs, sublist IDs, and line-level fields, see our guide on finding NetSuite record fields and relationships. This article focuses specifically on displaying related pricing rows safely on a custom record.
When should we use a read-only pricing sublist?
We should use a read-only pricing sublist when users need pricing context but should not maintain pricing from the parent record. This is especially useful when pricing requires approval, effective dating, currency controls, or centralized governance.
A related pricing record is a stronger model than a long text field or a group of custom fields on the parent record. Each row can have its own internal ID, status, audit history, permissions, and dates. Saved searches can then filter the rows to show only active, approved, current, or relevant prices.
A view-only design fits situations such as:
Showing approved contract prices on a customer agreement
Displaying item pricing associated with a product program
Showing regional or subsidiary-specific prices
Reviewing quantity-break pricing without exposing maintenance controls
Presenting historical pricing rows for audit or reference
Giving sales users visibility while limiting pricing administration to a smaller role group
The design is less appropriate when users need to add or edit lines directly on the parent record. In that case, we should evaluate an editable custom sublist, a Suitelet, or a dedicated pricing maintenance form instead of trying to make a saved-search sublist behave like a transaction line editor.
How do we model the pricing records?
The data model determines whether the sublist remains accurate and maintainable. We should begin with a separate custom record type for each pricing row or for each governed pricing relationship, depending on the business process.
A practical pricing record includes a required parent reference, such as a custom List/Record field pointing to the agreement, program, or account record. The pricing record can then contain the item and commercial attributes needed by the search.
The most important field is the parent relationship field. Without it, NetSuite has no reliable way to determine which pricing rows belong on a particular custom record. The field should point to the exact parent record type and should be mandatory whenever the pricing row cannot exist independently.
We should also decide whether the item reference points to an Item record or whether the row supports item groups, categories, or other product structures. A pricing record designed only for item IDs will not automatically support item groups unless the data model and search logic account for them.
Common fields include:
| Field | Purpose |
|---|---|
| Parent record | Connects the pricing row to the custom record |
| Item | Identifies the priced item |
| Price level | Defines the NetSuite pricing tier, where applicable |
| Currency | Prevents ambiguous monetary values |
| Minimum quantity | Supports quantity-break pricing |
| Unit price | Stores the approved price |
| Start date | Defines when the row becomes effective |
| End date | Defines when the row expires |
| Approval status | Prevents unapproved rows from appearing |
| Subsidiary | Separates pricing by legal entity where needed |
We should avoid storing formatted display text as the source of truth. A value such as “$125, USD, 10+ units” is useful as a display result, but the underlying fields should remain separate so searches, workflows, reports, and integrations can evaluate them.
How do we create the saved search behind the sublist?
The saved search is the control layer for the view-only display. It determines which related pricing rows appear and which columns users see.
First, create a saved search for the pricing custom record type. Add the parent relationship field to the criteria so the result set can be scoped to the current custom record. The exact filter configuration depends on the custom record and NetSuite account configuration, so we should verify the field behavior in the saved search preview before placing the search on a form.
The search should also exclude records that should not be visible. For example, if the sublist is intended to show currently usable prices, criteria could include:
Approval status equals Approved
Inactive equals false
Start date is on or before today
End date is empty or on or after today
Parent record equals the current record
Effective dating deserves particular attention. A search that checks only approval status can display expired prices. A search that checks only dates can expose unapproved rows. The criteria should reflect the actual pricing authority used by the business.
The result columns should follow the order in which users make decisions. Item and description normally come first, followed by quantity, currency, price level, unit price, and validity dates. Add a status or source column if users need to understand why a row is visible.
We should not rely on a formula column as the only source of visibility logic. A formula can make a result easier to read, but the actual filtering belongs in the criteria where it is easier to test and audit.
A saved search can also include a formula-based display field, such as a readable quantity range or pricing label. However, formula fields should be used carefully. They improve presentation but do not replace the separate numeric and date fields required for reliable sorting and filtering.
How do we place the search on a custom record form?
After the saved search is working, configure it as a custom sublist on the parent record form. The exact labels vary by NetSuite account and feature configuration, but the process follows the same principle: select the related search, identify the parent relationship, and add the result to the appropriate sublist area.
Before publishing the form, verify four things:
The search is associated with the correct parent record type.
The parent relationship field is the field used to identify related rows.
The sublist is placed on the forms used by the intended roles.
The search does not expose edit or create controls that conflict with the read-only requirement.
The sublist should appear only when the current parent record has related pricing rows. If no rows appear, we should test the relationship field value, search criteria, record permissions, and form assignment in that order.
This is also where naming helps. Use a clear label such as Approved Item Pricing or Current Contract Prices, rather than a generic label such as Custom Sublist. A meaningful label tells users whether the rows represent approved prices, historical records, or all related pricing entries.
How do we keep the pricing sublist truly view-only?
A view-only sublist should be protected at more than one layer. The saved-search presentation provides the read-only interface, but the underlying pricing records still require appropriate permissions.
The strongest design separates visibility permissions from maintenance permissions. A sales role might have View access to pricing records, while a pricing administrator has Create, Edit, and possibly Delete access. Users who should see the parent record but not the pricing data should not receive access to the underlying custom record type merely because the sublist exists.
We should test the following user actions:
Open the parent custom record
View the pricing sublist
Open a related pricing row
Edit the related row
Create a new pricing row
Delete a pricing row
Export search results
Access the pricing custom record through global search
Access the pricing record through a direct URL
A read-only sublist does not automatically make the underlying record inaccessible. If the role can edit the related pricing record, the user may still be able to open and change it from the sublist or another navigation path. Permissions and form restrictions must reinforce the intended control model.
Workflows can add another safeguard. For example, approved pricing records can be locked from ordinary edits, while changes require a status transition or approval action. This protects the source records even if a user has broader access than the display requirement suggests.
What should we do when pricing values are sourced dynamically?
NetSuite pricing data can depend on item, customer, price level, quantity, currency, subsidiary, and effective dates. A view-only sublist should display the authoritative stored result, not attempt to recalculate commercial rules in the browser.
If the pricing record is populated by SuiteScript, the script should set dependent fields in a deliberate order. For example, the item and currency should be established before the script derives or stores a price value that depends on them. When client-side sourcing is involved, `forceSyncSourcing` can help address timing in supported SuiteScript operations, but it should not be treated as a substitute for server-side validation.
This distinction is important:
Display logic controls what the user sees.
Pricing logic determines which price is valid.
Validation logic prevents incorrect data from being saved.
Permission logic controls who can change the source.
Keeping these responsibilities separate prevents a custom sublist from becoming an accidental pricing engine. For broader SuiteCommerce pricing decisions, our guide to dynamic pricing with SuiteScript for B2B catalogs covers server-side pricing authority and governed contract-pricing records.
How should we test the finished sublist?
Testing should begin with data relationships, not visual appearance. A sublist can look correct while showing rows from the wrong parent if the search filter is too broad.
Create test records that cover both valid and invalid combinations. Include an approved current price, an expired price, an unapproved price, a row linked to another parent record, and a row with a different currency or subsidiary. Then confirm that each record appears or disappears according to the intended rules.
Also test dates around boundary conditions. A price ending today may be valid through the end of the day, or it may become invalid at the start of the day, depending on the business rule and account timezone. Document that rule before writing the search criteria.
Finally, test the display under the actual roles that will use it. Administrator visibility does not prove that the intended role has the necessary search, custom record, subsidiary, or field permissions. Verify both the parent form and direct access to the related pricing record.
If the sublist is part of a wider NetSuite design involving integrations, forms, workflows, and custom records, our NetSuite services team can help review the data model and permission boundary before implementation.
Common implementation mistakes
The most common mistake is creating a search that returns all pricing records instead of only records related to the current parent. A correct parent relationship field is essential.
Another mistake is exposing every pricing row without defining status and date rules. Users then see expired, pending, duplicate, or superseded values and lose confidence in the sublist.
A third mistake is putting the price in a text field without currency or quantity context. A number such as `125.00` is incomplete unless users know the currency, unit basis, minimum quantity, and validity period.
We should also avoid using a client script to simulate read-only behavior by disabling fields after the page loads. Client-side restrictions improve the interface but do not provide reliable authorization. The saved-search sublist, custom record permissions, workflow controls, and server-side validation should establish the actual security boundary.
Finally, do not make the sublist responsible for transactional price enforcement unless it is connected to the transaction pricing process. Showing an approved price on a custom record does not automatically force that price onto a sales order. Transaction validation requires its own server-side rule and testing.
Conclusion
A NetSuite view-only pricing sublist is best implemented as a controlled presentation of related pricing records, not as a copied set of fields or a browser script that disables editing. Store each pricing row with a clear parent relationship, use a saved search to filter approved and current data, place that search on the custom record form, and separate viewing permissions from pricing-maintenance permissions.
This approach gives users the pricing context they need while preserving approval, audit, currency, quantity, and effective-date controls. When the design also needs automated pricing updates, transaction enforcement, or cross-system synchronization, review the full data and authorization model before adding scripts. For help assessing that architecture, contact Versich to discuss the right NetSuite customization path.
