You write a script. You test it. It fails. NetSuite tells you "invalid field." You check your code three times. Everything looks right. The problem? You guessed the field name.
NetSuite provides three browser tools to prevent this exact problem. These online reference guides show you the real field IDs and record types. They help you avoid hours of debugging. Using them is faster than trial and error.
Key Takeaways
- The browsers show supported records, fields, sublists, and related operations
- The SuiteScript Records Browser lists only records that officially support SuiteScript
- Account-specific metadata may require proper roles and permissions to view
- NetSuite updates its development references with each release
- Three browsers exist: SOAP Schema, SuiteScript Records, and REST API
What Is the NetSuite Schema Browser?
The SOAP Schema Browser shows every record and field available through SOAP web services. Think of it as a data dictionary for XML-based work. It shows field names, data types, and which fields are required.
This browser lives on the NetSuite Help Center. You do not install anything. Just open the URL and start browsing. The left panel shows an A-Z list of records. Click any record to see its fields and sublists.
Key Information in the Schema Browser
Each record page shows important details. You can see the field name, its type, and whether it is required.
- Field Name is the exact ID to use in your SOAP requests.
- Type tells you if it is a string, integer, date, or RecordRef.
- Cardinality shows whether the field is required.
A value of "1..1" means the field is required. Your integration will fail without it. A value of "0..1" means optional. And "0..unbounded" means you can send multiple values.
The browser also shows Label and Help Text. Label is the friendly name shown in the NetSuite UI. Help Text explains what the field does.
What Is the NetSuite Records Browser?
The SuiteScript Records Browser serves a different purpose. It shows what records and fields work with SuiteScript. This is the tool for internal scripts and workflows.
When you write a User Event script or Client script, you need exact field IDs. The Records Browser gives you these IDs. It also shows which sublists exist on each record. And it lists available search filters and joins.
How It Differs from the Schema Browser
The SOAP Schema Browser focuses on external work using XML. The Records Browser focuses on internal scripts using JavaScript. A field might exist in one browser but not the other.
Account-specific custom records need extra care. SuiteScript can work with custom record instances. However, the standard Records Browser cannot list every custom record created inside each customer account. Developers often find those IDs through field-level help or NetSuite's internal ID settings.
The REST API Browser
NetSuite also provides a REST API Browser for modern work. It uses OpenAPI 3.0 format and shows JSON structures instead of XML. If you build a mobile app or modern web work, this is the browser to use.
The REST browser shows CRUD operations. CRUD stands for Create, Read, Update, and Delete. You can see the exact request parameters and response structures for each record type.
The REST API Browser focuses on records, operations, fields, and response structures. Oracle's authentication guides explain tokens, certificates, permissions, and request headers.
Why Every NetSuite Developer Needs These Tools
Skipping the browser and guessing field IDs wastes time. You might get lucky sometimes. But you will hit errors that take hours to debug. The browser lookup takes five minutes.
Reduced Trial and Error
Looking up the field ID once is faster than running failed scripts. The browsers help you avoid common mistakes. You can see if a record type supports SuiteScript before you start coding.
This is especially helpful on records with many fields and sublists. Sales orders, customers, items, and projects can have large data structures. A quick lookup is usually easier than reading several failed script logs.
Error Prevention
The browsers help prevent common errors. These include unsupported records, wrong field IDs, and incorrect sublist names. They show which operations each record type supports.
Not every field restriction appears in one browser table. Form settings, roles, scripts, workflows, features, and business rules can affect whether a value can be changed. The browsers give you a good starting point.
Junior Developer Independence
With clear documentation, junior developers can work on their own. They do not need to ask a senior developer for every field ID. This frees up your senior team for harder problems.
Using the Browsers for SuiteScript Development
When you write SuiteScript code, you use the N/record and N/search modules. Both require exact field IDs. The Records Browser is your main reference.
Finding Field IDs for Scripts
Say you need to set a value on a sales order. Open the Records Browser. Navigate to "salesorder." The Fields table shows every field on that record. Find your field. Copy the ID exactly as shown.
Here is a common workflow:
- Open the SuiteScript Records Browser
- Use the A-Z index or namespace dropdown
- Click on your target record type
- Review the Fields table for the field ID you need
- Check the Sublists section if working with line items
- Copy the exact ID into your script
This approach works for creating workflows, building saved searches, and writing any custom script.
Debugging with the Records Browser
When a script fails, check the browser first. Make sure your field ID matches exactly. Make sure the ID belongs to the correct record type.
The browser also shows transformation IDs. Transformations let you create one record from another. For example, creating an invoice from a sales order. The browser lists which transformations each record supports.
Browser Tools for Integration Projects
External integrations connect NetSuite to other systems. You might sync customers from a CRM. Or push orders to a fulfillment warehouse. The Schema Browser and REST API Browser support these projects.
Mapping Data Fields
Every integration requires field mapping. You match fields in the external system to fields in NetSuite. The browser shows you exactly what fields exist. It also shows what data type each expects.
For BigCommerce integrations, you would map product fields between systems. The browser tells you which NetSuite fields accept string vs. number values. This prevents data type errors during sync.
Setting Up OAuth 2.0
Modern integrations use OAuth 2.0 for authentication. The REST API Browser documents record structures. Separate Oracle guides cover the authentication setup. You need both to build a complete integration.
Troubleshooting Sync Errors
When an integration fails, check the browser. Verify that the field you are trying to update actually exists. Confirm the data type matches what you are sending.
Sometimes a field works in the UI but not via API. The browser documents some of these cases. Look for notes in the field details.
Comparing All Three Browsers
Each browser serves a different purpose. Choose based on your project type.
Decision Guide
Use SOAP Schema Browser if:
- You maintain legacy SOAP integrations
- Your external system only supports XML
- You need batch operations like addList or updateList
Use SuiteScript Records Browser if:
- You write User Event, Client, or Scheduled scripts
- You build NetSuite workflows
- You need field IDs for internal development
Use REST API Browser if:
- You build modern REST integrations
- You prefer JSON over XML
- You want account-specific record metadata
For SuiteQL queries, use the Records Catalog and SuiteQL documentation. The REST API Browser documents the REST Record API, not SuiteQL specifically.
Advanced Tips for Browser Users
Once you know the basics, these tips help you work faster.
Use the Namespace Dropdown
The browsers organize records into namespaces. Instead of scrolling through the A-Z list, use the dropdown. Filter by category. For example, select "transactions" to see only transaction records.
Check Cross-Browser Links
The browsers link to each other. When viewing a record in the SOAP browser, click the link to see SuiteScript support. This shows when a record works in SOAP but has limited scripting options.
Review Release Notes
NetSuite updates the browsers with each release. New records and fields may appear. Existing support can also change. Check the Oracle documentation for your version.
Bookmark All Three Browsers
Save time by bookmarking each browser URL. During development, you can quickly switch between them. Most developers need the Records Browser for daily scripting. They use the SOAP or REST browser for integration work.
Common Mistakes to Avoid
Using Old Browser Versions
Use the Records Browser for the latest NetSuite release. Oracle supports only the current version. Older versions show deprecated fields. These may cause production errors.
Confusing SOAP and SuiteScript Field Names
Field names sometimes differ between browsers. The SOAP Schema might call a field "entity." SuiteScript might call it "customer." Always check the specific browser for your use case.
Ignoring Cardinality Rules
The cardinality column tells you if a field is required. A "0..1" field seems optional. But some have default values that change behavior. Test in sandbox before production.
Missing Custom Records
Account-specific custom records may not appear in the public browser pages. The public browsers mainly document standard platform definitions. They cannot list every custom record created inside each NetSuite account. Check with your administrator for account-specific IDs.
Preparing for NetSuite Developer Certification
NetSuite offers developer certifications. These exams test your knowledge of these tools. Understanding the data model is essential for passing.
The certification covers record types and their relationships. It also covers field types and cardinality. You need to know SuiteScript module usage. And you need to understand integration best practices.
Hands-on practice with the browsers builds the skills you need. Create test scripts that reference different record types. Verify your field IDs against the browser. This practical experience prepares you better than reading alone.
How Anchor Group Helps NetSuite Developers
When you need help with NetSuite development or integration projects, Anchor Group brings technical expertise. Our team uses these browser tools daily. We know the shortcuts that save time.
Our NetSuite services cover everything from custom scripts to complex integrations. We work on SuiteCommerce implementations that require careful field mapping and data sync.
If you have a specific issue and need quick help, our free 30-minute fix consultation lets you talk with a real NetSuite expert. We can review your script errors. We can check your field mappings. Or we can point you to the right browser documentation.
Working with us feels like calling a neighbor for help. No fuss, no overselling. Just practical answers from people who know NetSuite.
Frequently Asked Questions
What is the main difference between the Schema Browser and Records Browser?
The SOAP Schema Browser shows fields for XML-based work. The SuiteScript Records Browser shows fields for internal JavaScript scripts. A field might exist in one but not the other. Always use the browser that matches your project type.
Can I find custom fields and records in these browsers?
The public browsers mainly document standard platform definitions. They cannot list every custom record created inside each NetSuite account. SuiteScript can work with custom record instances. But you may need to find account-specific IDs through field-level help or internal ID settings.
Are these browsers available to all NetSuite users?
Public documentation is available online through Oracle Help Center. Account-specific metadata and related features may depend on your role and permissions. Check with your administrator if you need access to custom objects or restricted records.
How do these tools help with debugging SuiteScript?
When a script fails with "invalid field" errors, check the browser. Verify your field ID matches exactly. Confirm the field exists on your record type. Check if it is read-only. This often reveals the problem in minutes.
What should I do if a field works in the UI but not in my script?
Some fields are editable in the UI but limited via API. The browser shows some of these restrictions. Look for notes about access. If the field cannot be set via script, you may need a workflow or manual entry instead.
Related Articles