Supported action types
The Send to NetSuite step supports four action types. The right choice depends on what you’re trying to do.- Create
- Update
- Transform
- Upsert
Creates a new record in NetSuite.Use this when your source data represents something that doesn’t exist in NetSuite yet — a new purchase order from a supplier spreadsheet, a new sales order from a customer order file, a new inventory adjustment.Common record types for Create:
- Sales Orders
- Purchase Orders
- Inventory Adjustments
- Journal Entries
How schema works
Every time you add a Send to NetSuite step to the canvas, Parabola makes a live call to your NetSuite account and pulls the current field schema for that record type. This means:- The field list in the step reflects your specific account’s configuration — including any custom fields you’ve added
- If a new required field is added to a custom form, it will appear in the step the next time you open it
- Schema is pulled fresh each time — no manual refresh needed
Field names vs. UI labels
When you can’t find a field by its UI label, use the XML view trick to look up the exact API name.Finding field names with the XML view
- Open any NetSuite record of the type you’re working with (e.g., an existing PO)
- At the end of the URL, add
&xml=Tand press Enter - The page renders as XML, showing the exact field names the API uses — these match what you’ll see in the Send to NetSuite step
Custom forms with additional required fields
NetSuite allows accounts to create custom forms with mandatory fields beyond NetSuite’s defaults. The Send to NetSuite step only knows about the standard required fields — it doesn’t automatically detect custom form requirements. What this looks like: The record creation fails with a validation error, even though you’ve mapped everything the step shows as required. Fix: Identify which custom fields are mandatory on your form, and map values to those fields manually in the step — even if they aren’t flagged as required. Your NetSuite admin can tell you which form is in use and what its additional required fields are.Bulk creation and line-item grouping
When your input data has multiple rows that belong to the same parent record — for example, a spreadsheet of order line items where several rows share the same order number — use the grouping feature in the Send to NetSuite step to specify which column identifies the parent record. Parabola will consolidate matching rows into a single record with multiple line items before sending.Testing safely
To test in sandbox:- Set up a separate authorization using your sandbox account ID (e.g.,
12345-sb1) - Configure the Send to NetSuite step to use the sandbox credential
- Run a test with 2–3 rows and verify the records in NetSuite before running at scale
- Switch to your production credential only after the flow is confirmed working
FAQs
What happens if one record fails to create? Does the whole flow stop?
What happens if one record fails to create? Does the whole flow stop?
It depends on how the flow is configured, but by default, a failed record will log an error in the flow run history — other records in the same run may still succeed. Check the flow run log in Parabola to see which rows succeeded and which failed, then inspect the error messages to understand what went wrong.
Can I send to multiple record types in the same flow?
Can I send to multiple record types in the same flow?
Yes — just add multiple Send to NetSuite steps to the canvas. Each step can target a different action type and record type. For example, you could create a PO in one step and then transform it to an item receipt in a second step.
How do I confirm a record was actually created in NetSuite?
How do I confirm a record was actually created in NetSuite?
Two ways: check the flow run log in Parabola (it will show a success or error response for each record), then verify directly in NetSuite by searching for the record. For the first few runs of any new flow, it’s worth confirming in NetSuite directly rather than relying solely on the Parabola log.
Do I need to include all fields, or just the required ones?
Do I need to include all fields, or just the required ones?
You only need to map the fields that are required — and any optional fields you specifically want to populate. The step will leave unmapped optional fields blank (or populated with NetSuite’s defaults). Required fields are flagged in the step and must be mapped before the flow will run successfully.
What’s next
You’ve completed all the core lessons. Head to the final lesson for a course recap and to claim your certificate.Building challenge
Configure a Send to NetSuite step using the internal ID lookup you built in Lesson 5. Stop before running — you’re setting up, not executing.You’re done when: The Send to NetSuite step shows no unmapped required fields and all object-reference fields are mapped to internal ID columns. Your flow is configured end-to-end.
Add a Send to NetSuite step to your flow
Connect it after the Combine Tables step from Lesson 5 (the one with internal IDs joined to your input data).
Select the action type and record type
Choose the action type and record type that match your use case — for example, Create and Purchase Order if you’re following the PO example. The step will load the field schema from your NetSuite account.
Map object-reference fields to internal ID columns
For any field that references another NetSuite object — Vendor, Customer, Item, Location, Subsidiary — map it from the corresponding Internal ID column in your dataset, not the name column. This is the pattern that makes Send flows reliable at scale.
Map remaining required fields
Walk through any other required fields the step flags. Check for Subsidiary — it’s required for most transaction types. Map it to an internal ID, or set a custom/default value if all your records go to the same subsidiary.