..avif)
You're not here because you need convincing that NetSuite integration monitoring matters. You already know.
You're here because orders went missing, a sync failed overnight, or close took three days longer than it should have and nobody caught it until the damage was done.
This guide builds a complete NetSuite integration monitoring system using saved searches, workflows, and custom fields you already have access to.
No middleware subscriptions. No new vendor logins. No additional tools.
This framework runs across 60+ NetSuite environments in wholesale distribution, manufacturing, and e-commerce.
The organizations using it catch NetSuite integration failures in minutes, not during close, and not after a customer calls.
Three Ways NetSuite Integrations Actually Fail
Most teams only monitor for one failure type. That's the problem.
- Loud failures: A script errors out. A workflow fires a notification. An import throws an error message. These are the easiest to catch and the ones most teams have already handled.
- Silent failures: The integration completes without errors but produces wrong results: duplicate records, missing fields, incorrect GL accounts, transactions not connected to the right parent records. Everything looks fine until reconciliation surfaces the problem - often days later.
- Timing failures: Data arrives too slowly to be useful. The order syncs four hours after placement. The payment posts the next morning. The integration technically works, but it can't support same-day fulfillment or real-time reporting.
Here's the real question:
If your Shopify integration ran this morning but created 40% fewer records than yesterday, who notices first? Your monitoring system or your warehouse manager asking why pick lists are short?
For most organizations without this framework: it's the warehouse manager. That's the gap this guide closes.
Why Integration Monitoring Fails in Most Organizations
Nobody's job description says "check integration logs daily."
It falls to whoever built the integration, the admin who inherited it, or whoever customer service calls first when orders go missing.
That's why most organizations find out about NetSuite integration failures from customers rather than dashboards. It's one of the most common integration gaps teams inherit after go-live.
Three patterns explain why this keeps happening:
Effective monitoring requires three things:
- Proactive detection: Finding problems before they're reported.
- Continuous validation: Confirming things work every sync cycle.
- Accessible visibility: Putting monitoring where operational teams actually look, which is inside NetSuite.
What Should I Monitor for NetSuite Integrations?
Comprehensive data sync monitoring covers four questions:
- Execution monitoring: Did the integration run? Did it attempt to execute as scheduled? This catches scheduled script failures, workflow gaps, CSV import interruptions, and API call failures.
- Data validation monitoring: Did it create the right records? Even when integrations execute successfully, they can produce wrong results. This layer validates record existence, completeness, accuracy, and relationship integrity.
- Exception detection: What unusual patterns appeared? Duplicate records, orphaned transactions, blank required fields, GL mapping errors, volume anomalies. These don't always represent failures - but they signal something changed.
- Performance monitoring: How fast did data move? Correct records can still fail business requirements when they arrive too slowly. Sync latency, processing duration, and queue depth all matter for time-sensitive processes. For help deciding between real-time and batch integration patterns, see the real-time vs. batch integration decision matrix.
The six processes below address all four questions. Work through them in order.
How to Build Your Integration Monitoring Foundation
Three foundational elements make everything else work. Don't skip them.
Custom Fields for Integration Tracking
Add these four custom fields to every record type your integrations touch:
- Source system identifier: The external record ID (Shopify Order Number, Salesforce Opportunity ID, payment gateway transaction ID). This is the key that lets you match NetSuite records back to source data for reconciliation.
- Integration timestamp: When the integration created or last modified the record. Enables time-based monitoring and latency detection.
- Integration status: A list field: Pending, Synced, Error, Manual. This single field drives most of the exception detection in this guide.
- Sync attempt count: How many times the integration tried to process this record. A count above 3 almost always signals a persistent error.
These fields do double duty: they power your monitoring searches and give your team immediate context when investigating a specific failure.
Standard Naming Conventions
When you're reviewing execution logs because orders aren't flowing, you don't want to spend ten minutes figuring out which of seven scripts named "sync_v2_FINAL" is the one that broke.
Use these conventions before building anything else:
- Scripts: INT_[SourceSystem]_[Function] - e.g., INT_Shopify_OrderImport
- Custom records: Integration Queue - [Source]
- Workflows: INT Workflow - [Function] - e.g., INT Workflow - Sales Order Validation
Consistent naming means your execution log saved searches can filter by prefix and instantly surface everything integration-related.
Integration Documentation Repository
Create a single location (a custom record, internal wiki, or shared document) containing:
- Integration inventory: Every active integration, its purpose, frequency, and owner.
- Data flow maps: What moves from where to where, including field mappings.
- Expected volumes: Normal record counts per sync cycle (your baseline for anomaly detection).
- Error escalation paths: Who handles failures for each specific integration.
- Reconciliation procedures: Step-by-step instructions for validating each integration's output.
When something breaks on a Friday night, whoever's on call needs to know what they're looking at without calling three people first.
Process 1: Execution Monitoring with Script Logs and Saved Searches
NetSuite's script execution log captures every script run, including all your integration scripts. The problem is it's passive. Nobody looks at it unless they're already investigating something.
This process turns passive logs into active monitoring.
Build this saved search:
- Search type: Script Execution Log
- Filters: Script Name contains "INT_" | Log Level: Error, Emergency | Date: Within last 24 hours
Results columns to include:
Summary: Group by Script with COUNT of errors. A script with 47 errors in 24 hours needs different treatment than one with 2.
Schedule automatic alerts:
- Recipients: Integration team, operations manager
- Frequency: Hourly during business hours; once at 7 am for overnight issues
- Condition: Send only if results exist
That last condition is critical. Alerts that fire when there's nothing to report train people to ignore them and ignored alerts are worse than no alerts at all.
Process 2: Data Validation Through Reconciliation Searches
Execution monitoring tells you the integration ran. These searches tell you whether it ran correctly, which is where most integration error handling gaps actually live.
Search 1: Missing Records Detection
- Search type: Transaction
- Filters: Type = Sales Order | Source System Order ID field: Is Empty | Date Created: Within monitoring window
If your integration correctly populates the source system ID field on every record it creates, a blank value means the record was created some other way or wasn't created when it should have been.
Any result here deserves investigation.
Search 2: Duplicate Record Detection
Duplicates happen when integrations don't check whether a record already exists before creating a new one.
A $200 order that creates two sales orders and ships twice is an expensive way to find out your integration lacks idempotency controls.
- Search type: Transaction
- Filters: Type = Sales Order | Source System Order ID: Is Not Empty | Main Line: Yes
- Summary: Group by Source System ID with COUNT - any ID with count above 1 is a duplicate
Schedule this search to run after every integration cycle and alert immediately when any count exceeds 1.
Search 3: Incomplete Record Detection
Records that exist but are missing required data create downstream problems that are hard to trace back to their source. A sales order with no customer can't be invoiced. A sales order with no items can't be fulfilled.
Use a formula criteria to find missing critical fields:
CASE
WHEN {entity} IS NULL THEN 'Missing Customer'
WHEN {item} IS NULL THEN 'Missing Items'
WHEN {custbody_payment_method} IS NULL THEN 'Missing Payment'
ELSE NULL
END
Filter where formula IS NOT NULL. Every result is a record that made it into NetSuite in a state that will cause problems downstream.
Process 3: Exception Detection with Highlighting and Thresholds
Even when integrations execute and create complete records, unusual patterns can signal problems before they compound.
Volume Anomaly Detection
If your Shopify integration typically creates 150–200 sales orders per day and today it created 12, would anyone notice before the warehouse asked why pick lists were empty?
- Search type: Sales Order
- Filters: Created By = Integration user | Date Created: Today
- Add highlighting rules:
- Count below your low threshold: Red (likely a failure or processing gap)
- Count above your high threshold: Orange (possible duplicate creation or data flood)
Base thresholds on 30 days of historical averages. Review quarterly as your business volume changes.
For a broader look at what performance degradation looks like inside NetSuite, see the 47-point NetSuite performance audit guide.
GL Account Mapping Verification
Integrations that post to wrong GL accounts create financial reporting problems that don't surface until close. By then you're doing correcting journal entries instead of finding the root cause.
Use a formula to flag transactions routed to unexpected accounts:
CASE
WHEN {account} NOT IN ('4000', '4100', '4200')
THEN 'Invalid Account'
ELSE NULL
END
Substitute your actual revenue and clearing account numbers. Filter where formula IS NOT NULL.
Aging Integration Queue Monitoring
Items in your integration queue shouldn't sit for long. If they are, something's stalled.
- Search type: Custom Record (Integration Queue)
- Flag anything over your SLA threshold, typically 1-4 hours depending on integration frequency.
- Items sitting in queue for 24+ hours have almost certainly failed without logging an error.
Process 4: Workflow-Based Alerting for Real-Time Notification
Saved searches run on schedules. Workflows fire the moment something happens. You need both because some failures can't wait for the next hourly check.
Integration Failure Workflow
- Record Type: Sales Order
- Trigger: After Record Submit
- Condition: Integration Status field equals "Error"
Actions in sequence:
- Send email to integration team with record ID and error field value.
- Create task assigned to operations manager, due today.
- Update a "Flagged for Review" checkbox to true.
The email gets immediate attention. The task ensures follow-through if the email gets buried. The checkbox lets your monitoring searches filter for records that had errors but haven't been reviewed.
Duplicate Prevention Workflow
Prevention rather than cleanup. Run before a record saves to block duplicates before they reach the warehouse.
- Record Type: Sales Order
- Trigger: Before Record Submit
- Condition: Source system ID field IS NOT NULL AND a saved search for existing records with that ID returns results.
- Action: Display error message that stops the save and logs the attempt for investigation.
One wholesale distributor we support was creating duplicate sales orders for roughly 3% of Shopify orders due to a retry logic issue in their middleware.
This workflow caught every one before they reached the warehouse.
Performance Monitoring Workflow
Performance degradation rarely announces itself until it becomes a full failure.
- Record Type: Custom Record (Integration Execution Log)
- Trigger: After Record Submit
- Condition: End time minus start time exceeds 3,600 seconds (one hour)
- Action: Send alert to integration team
Process 5: CSV Import Monitoring and Error Handling
CSV imports are one of the most common integration patterns and one of the least systematically monitored. Most teams check the status page when they remember, which isn't often enough.
Build the Import Status Tracker
Rather than manually checking Setup > Import/Export > View CSV Import Status, build a saved search:
- Search type: Saved CSV Import
- Filters: Status = Failed or Partial | Date: Within monitoring window
- Email alert: Send to operations team immediately when status equals Failed or Partial
Handling CSV Import Errors Without Manual Cleanup
NetSuite generates a results file for every import containing all records that failed to process. Build a systematic approach:
- Automatic retrieval: SuiteScript accesses import status and pulls error files programmatically.
- Error categorization: Parse error messages to identify whether failures are missing required fields, invalid references, format mismatches, or governance timeouts.
- Automated retry: For transient failures like locked records or timeouts, automatically resubmit after a delay.
- Manual queue: Route persistent errors to a custom record queue so a human reviews them before they get lost in email.
This turns CSV import monitoring from "someone checks the status page when they remember" into a self-managing error resolution workflow.
Process 6: REST and SOAP Integration Error Handling
Integrations using NetSuite's REST or SOAP web services present a different monitoring challenge: errors happen outside NetSuite's execution logs because they originate in external systems.
Capturing External System Errors Inside NetSuite
Build a RESTlet that external systems call to log integration activity directly into NetSuite.
When external systems post to this endpoint before and after NetSuite API calls, you get an audit trail of all integration activity visible inside NetSuite, not buried in middleware logs nobody checks.
For a deeper look at SuiteScript capabilities that support this kind of logging, see SuiteScript 2.1 vs 2.0: ES6 features and async/await.
function post(context) {
var logRecord = record.create({
type: 'customrecord_integration_log'
});
logRecord.setValue({ fieldId: 'custrecord_source_system', value: context.source_system });
logRecord.setValue({ fieldId: 'custrecord_status', value: context.status });
logRecord.setValue({ fieldId: 'custrecord_error_details', value: context.error_message });
logRecord.save();
return {success: true};
}
Monitoring Authentication Failures
- Search type: Login Audit
- Filters: Status = Failed | User = Integration service account | Date: Recent window
A spike in authentication failures indicates credential issues, token expiration, or security problems. This search catches the warning before the integration goes completely dark.
The Integration Monitoring Dashboard
All six processes are most useful when they're visible in one place. Consolidate your monitoring searches into a single NetSuite dashboard.
Portlets to include:
Access control: Share with Operations Managers, Integration Team, Finance Controllers, and Customer Service Managers.
Add KPI portlets for at-a-glance health:
- Percentage of successful runs in the last 24 hours
- Current queue depth
- Average processing time
- Time since last successful sync
This is the difference between monitoring that gets used and monitoring that gathers dust. Integration status becomes part of the daily NetSuite workflow rather than something living in a separate tool nobody logs into.
For more on building saved searches that teams actually use, see 10 NetSuite saved searches that will change how you use the platform.
Why Monitoring Tools Gather Dust (And What Actually Works)
Organizations buy middleware monitoring platforms with impressive dashboards and alerting capabilities. Six months later, nobody's checking them. Three patterns explain why:
- Separate login friction: Monitoring requires logging into a different system. Daily work happens in NetSuite, so monitoring gets pushed to "when there's time" which means it doesn't happen.
- Information disconnect: Monitoring tools show technical metrics (API calls, response times, error rates). Operational teams need business metrics (missing orders, duplicate payments, delayed syncs). The translation gap means nobody acts on what they see.
- Alert fatigue: Monitoring generates dozens of alerts daily. Teams learn to ignore them. Critical notifications get buried.
Effective NetSuite integration monitoring has to live where people actually work.
The four principles Stockton10 builds every monitoring engagement around:
- Start with business impact: Not "REST call failed with 500 error" but "15 customer orders didn't create sales orders and the warehouse can't fulfill them." Alerts written in business language get acted on.
- Build where people look: Monitoring appears on dashboards teams check daily, in searches they already run, through emails they actually read. No new login required.
- Make exceptions actionable: Every alert includes enough context to address the issue immediately: which integration failed, which records are affected, what the error says, and what to do next.
- Enable self-service investigation: Operations teams work through problems without calling IT. Saved searches provide detail, system notes show change history, custom fields capture integration metadata in plain language.
What Ongoing Integration Monitoring Looks Like in Practice
Here's the cadence organizations we support run consistently:
- Daily: Scheduled saved searches detecting missing records, duplicates, and incomplete data sent to operations teams each morning before the business day starts. If something broke overnight, they know before customers do.
- Real-time: Workflows triggering immediate notifications when critical integrations hit an error state. The right person gets alerted within minutes.
- Weekly: Comprehensive reconciliation comparing source system totals to NetSuite records, catching gaps that daily searches miss.
- Monthly: Dashboard review showing performance trends: success rates, processing duration, volume patterns, error categories.
- Quarterly: Alert threshold tuning and adjustments for business changes. An integration handling 200 orders daily six months ago needs different thresholds now that you're processing 800.
These aren't one-time setups. They're ongoing practices that evolve as your integrations and business requirements change.
Not sure where your environment stands before committing to this cadence? A NetSuite health check gives you the baseline.
Catch Failures Before Your Customers Do
The gap between NetSuite integration monitoring theory and practice isn't technical capability. NetSuite already has execution logs, system notes, saved search functionality, and workflow tools.
The gap is organizing those capabilities into repeatable processes that surface problems before customers notice. That's what separates reactive NetSuite optimization from a system that actually compounds value over time.
The two futures every NetSuite organization is choosing between:
- Reactive discovery: Customer service escalates missing orders. Finance finds payment mismatches during close. The warehouse reports inventory discrepancies. The integration has been failing for hours or days, and cleanup is already underway.
- Proactive monitoring: Scheduled searches detect missing records immediately. Workflows alert teams to duplicate creation in real time. Dashboard portlets show integration health at a glance.
Your integrations are already generating the data you need. The only question is whether you're organized enough to catch failures in minutes or reactive enough to find out when a customer calls.
The processes above give you everything to build this yourself.
But if you want a Senior Architect to walk through your actual environment, show you exactly where your integrations are holding up and where they aren't, and hand you a 90-day roadmap before you hang up?
That call exists.
