What’s different from Pull
The Send to NetSuite step uses a different API than Pull from NetSuite:- Pull from NetSuite uses NetSuite’s SOAP API
- Send to NetSuite uses NetSuite’s REST API
Permissions for Send to NetSuite
Beyond the REST Web Services permission, the key difference is in how you set access on individual record types. For Pull from NetSuite, View access is sufficient — you only need to read data. For Send to NetSuite, the relevant record types need Full access — Full means both read and write. Example permissions for creating purchase orders:| Permission | Level |
|---|---|
| REST Web Services | Full |
| Purchase Orders | Full |
| Items | View |
| Vendors | View |
| Locations | View |
Permissions in NetSuite are set at the record type level — you can’t restrict access to specific fields within a record. If the role has Full access to Purchase Orders, it can read and write any field on a PO.
Why internal IDs are required
When you send data into NetSuite, every reference to another object must be provided as that object’s internal ID — not its name. This applies to everything: vendors, items, customers, locations, subsidiaries, cost centers, currency codes — all of them. NetSuite doesn’t do name-matching when receiving data via the API. Why this matters in practice: Even a small formatting difference — an extra space, a slightly different spelling, a name that’s been updated — will cause a record creation to fail when using names. Internal IDs are stable numbers that don’t change. As a general rule: once you’re building Send to NetSuite flows, use internal IDs everywhere. They have a much higher success rate than name-based matching.Finding internal IDs: two patterns
- Pull from NetSuite reference searches
- Google Sheets lookup template
The most reliable approach: create saved searches in NetSuite for each object type you need to reference — Items, Customers, Vendors, Locations, Subsidiaries — and pull those into your Parabola flow before the Send step.A complete Send to NetSuite flow typically looks like:
- Input data (from spreadsheet, PDF, another system, etc.)
- Pull from NetSuite — Vendor reference search (name + internal ID)
- Pull from NetSuite — Item reference search (name + internal ID)
- Combine Tables — join input data to reference searches to look up IDs
- Send to NetSuite — create or update records using the mapped IDs
Subsidiary is almost always required
For most transaction types in NetSuite — journal entries, purchase orders, sales orders — subsidiary is a required field. If you try to create a record without specifying the subsidiary, it will fail. If all of your flows write to the same subsidiary, you can simplify this by setting a custom/default value directly in the Send to NetSuite step rather than looking it up dynamically each time.What’s next
Now that you understand why internal IDs are required and how to look them up, the next lesson covers the supported action types, how to map fields correctly, and the most common gotchas that cause records to fail. In the building challenge there, you’ll wire your vendor reference search directly into a Send to NetSuite step.Building challenge
Build a reference search for the object type you’ll need to look up internal IDs for. The steps below use Vendor as the example, but the same pattern applies to Items, Customers, Locations, Subsidiaries — whatever your Send flow will reference.You’re done when: You have a Combine Tables step whose output includes an Internal ID column with numeric values for every row. That output feeds directly into the Send to NetSuite step in Lesson 6.
Create a reference saved search in NetSuite
Go to Reports > Saved Searches > All Saved Searches > New and select the search type that matches the object you need to look up (e.g., Vendor, Item, Customer). Under Results, add two columns: Name and Internal ID. No criteria needed — you want the full list. Make it public and save.
Pull it into Parabola
Add a Pull from NetSuite step to your flow alongside the saved search from Lesson 3. Select the matching search type and find your new reference search. Confirm it returns two columns: names and internal IDs.
Join it to your input data
Add a sample data step (or pull in a small spreadsheet) with a name column representing what your source data would look like. Use a Combine Tables step to join this to your reference search on the name column. Confirm the output now includes an Internal ID column for each row.