ExtendInsights updates and creates NetSuite records using SOAP Web Services (SuiteTalk). Because of that, NetSuite workflows and scripts may run differently than when users edit records directly in the NetSuite UI.
What controls whether a NetSuite workflow runs?
For workflows, the primary control is the Contexts setting in the workflow:
If you do not want the workflow to run during ExtendInsights uploads
In the workflow, remove SOAP Web Services from Contexts.
If you do want the workflow to run during ExtendInsights uploads
In the workflow, include SOAP Web Services in Contexts.
This gives admins precise control over whether a workflow runs for:
NetSuite UI updates (User Interface context)
ExtendInsights updates (SOAP Web Services context)
Other integration contexts (if applicable)
What about scripts?
For scripts, behavior depends on the script type and how it is configured (for example, whether it is enabled to execute in web services / integration contexts). The key practical point is:
If a script is configured to run when records are processed via SOAP Web Services, it can run during ExtendInsights uploads.
If it is restricted to UI-only behavior, it may not run during ExtendInsights uploads.
If you are unsure which scripts are running, the fastest approach is to review the script deployment/execution context settings and validate with a small test upload.
Performance Impact (Important)
Workflows and scripts can slow down uploads, especially when:
They run on every record in a batch
They perform heavy field updates, searches, or approvals
They trigger downstream processes (emails, additional record creation, etc.)
If uploads are slower than expected, review any workflow/script that runs in SOAP Web Services context and consider:
Disabling SOAP Web Services context for non-essential logic
Narrowing workflow conditions so it runs only when necessary
Testing with a small batch first
Control your workflow by enabling/disabling SOAP Web Services
