To find NetSuite SOAP integrations, combine observed API activity with application configuration, scheduled jobs and confirmation from the people who operate each business process. A dashboard can show active requests. It cannot, by itself, prove that you have found every quarterly export, dormant recovery job or supplier-managed connection.
The useful deliverable is a flow inventory with an owner, evidence and a next action for each dependency. This article explains how to produce that inventory before a SOAP migration, endpoint change or integration review.
Ask operations and finance which activities depend on information entering or leaving NetSuite. Start with order entry, fulfillment, billing, payment reconciliation, payroll journals, stock availability, purchasing and management reporting. Include processes where a person downloads a file and imports it elsewhere; a background SOAP job may prepare that file even though the final handoff appears manual.
For each process, identify the person who would notice a failure. This is often a different person from the developer or software supplier. The finance manager may know that a month-end file is missing, while the integration administrator knows where the connection runs.
Give each flow a durable identifier, such as INT-014. Keep that identifier in the inventory, test plan and future support documentation. Record names can change; the inventory needs a stable way to connect evidence over time.
Oracle's SOAP Web Services Analysis dashboard includes operation performance, API-version usage and record-processing information. It is a useful starting point for identifying which endpoint versions are actually appearing in requests. The documented navigation is Customization, Performance, SOAP Web Services Analysis, subject to the relevant SuiteApp access.
Use the available date range and integration filter deliberately. A view of the last day can miss a weekly batch. Oracle documents presets up to 30 days in this dashboard, with different chart resolutions, so record the period represented by each export.
Retain enough information to connect the observation to the inventory: application or integration name, operation, endpoint version, time window and supporting log reference. Where a dashboard supports an export, preserve a dated copy in the project's authorized evidence location. Oracle documents CSV export routes for SOAP operation and record-processing logs.
Do not copy tokens, passwords or complete sensitive transaction payloads into a shared discovery workbook. Record where authorized technical staff can find protected evidence instead.
APM's SOAP and REST analyses show synchronous requests. Their observations should be supplemented for asynchronous work. Oracle also notes that performance history does not carry across an account's move to a new OCI data center. A short observed history after such a move needs an explanation in the inventory.
Other discovery gaps are operational rather than product limitations:
Treat “not observed” as an evidence state. It does not mean “safe to remove.” Equally, a configured connection is not proof that it still supports an active business process.
For every connected application, ask its owner to identify the actual NetSuite communication method. A product name or a connector label is not enough. The same platform may use native REST, a RESTlet, SOAP and file transfer for different flows.
Request a configuration export or screenshot that identifies the connection and its method, without exposing credentials. Inspect job schedules, deployment variables, application documentation and vendor release guidance through the authorized team. If a service provider manages the connection, ask which operations remain SOAP-dependent and who is responsible for replacing them.
Keep vendor statements scoped. “Our main connector uses RESTlets” does not answer whether its file export still uses SOAP. “No immediate action is needed” can apply to a managed product while leaving the customer's custom jobs untouched.
A NetSuite integration review should reconcile these external dependencies with the account evidence, rather than relying on either source alone.
Use the following fields as a starting point. Add details only when they support a migration or operating decision.
| Inventory field | Why it matters |
|---|---|
| Flow identifier and business purpose | Connects the technical work to an operational outcome |
| Business owner and technical owner | Separates acceptance responsibility from maintenance |
| Source and destination | Makes direction and data ownership explicit |
| Integration application and environment | Prevents test and production evidence being mixed |
| Method and endpoint version | Identifies the actual SOAP dependency |
| Record types and operations | Supports a meaningful replacement assessment |
| Schedule and business calendar | Exposes infrequent or close-critical work |
| Maximum acceptable delay | Helps prioritize recovery and cutover |
| Evidence date and observation window | Shows how current and complete the conclusion is |
| Supplier commitment and next action | Makes externally owned work trackable |
If one application performs unrelated jobs, give the jobs separate rows and retain a shared application identifier. This avoids a false decision that the whole connection is migrated when only the most visible flow has changed.
Discovery is stronger when it compares three independently prepared lists:
Every item should reconcile across the lists or have an explained exception. An observed application with no business owner is a governance gap. A critical business process with no identified technical flow is a discovery gap. A configured job with no recent activity needs an owner to confirm whether it is infrequent, obsolete or broken.
Do not resolve these mismatches by deleting rows. Assign an investigation owner and due date. The unresolved count is part of the result of discovery, not an embarrassment to conceal.
A wholesale business initially finds three SOAP applications in its recent activity. Its teams believe those applications cover every integration. During process interviews, finance mentions a quarter-end customer rebate export that is prepared automatically.
The job is hosted in a supplier's environment and did not run during the selected observation period. It shares a service identity with a daily invoice export, which explains why the connection was already known but the business flow was absent from the first inventory.
The team adds a separate rebate-export row, records its next business date and asks the supplier for the replacement method and test evidence. Finance defines the acceptance criteria: the same eligible transactions, the same exclusions and an explained difference report.
No new technology was needed to find this dependency. The improvement came from using a process inventory alongside technical observations. This is a hypothetical example, not a claim about a CuriousRubik customer.
A high-volume order flow deserves attention, but a low-volume payment or close process can be equally consequential. Rank each dependency using business interruption, time sensitivity, recovery difficulty, replacement uncertainty and ownership confidence.
A useful first wave often includes a manageable flow that exercises the planned authentication and deployment model. That can establish the team's method before a more complex change. Do not confuse this learning choice with the final business-risk ranking.
For each flow, define the next decision: confirm ownership, validate coverage, obtain a supplier plan, build a proof of concept or prepare a cutover test. An inventory without next actions becomes stale quickly.
Assign a maintainer and update the record when a connection, role, schedule or deployment changes. Require new integrations to supply the same minimum information. Retire a flow only after its owner confirms the business dependency has ended and the authorized technical retirement is complete.
Hand the resulting inventory into NetSuite support documentation. Support staff should be able to find the affected process, owner, evidence location and recovery procedure when a failure occurs.
The discovery exit condition is not “we found a certain number of integrations.” It is “every known business dependency and configured connection has a supported classification, and the remaining uncertainty has an owner.”
No. Check the observation period, asynchronous jobs, infrequent processes, external suppliers and available history. Record the limitation instead of treating absence of recent observations as conclusive.
Only if it represents one independently managed business flow. Separate flows with different schedules, owners, records or migration paths, while preserving their shared application reference.
Yes. Business users can identify missing outputs, critical dates, manual workarounds and downstream decisions. Technical staff then trace the connection responsible for those outcomes.
Ask for the affected flows, communication method, replacement responsibility, delivery plan and test approach. Avoid accepting a broad product statement as confirmation about your configured integration.
No. First establish ownership and business impact. Discovery produces evidence and recommendations; changing or retiring access requires an authorized, controlled action.