Fix Guide

How to Fix ServiceNow Incidents Not Syncing to External Systems

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

ServiceNow incident sync failures fall into three categories: outbound REST messages stuck in the ECC queue when the target system rejects auth or returns 5xx, business rules with async-onUpdate that silently fail when the integration script throws, and transform map field mappings that drop required fields when source data has unexpected null values. The fix workflow: inspect sys_rest_message for failed messages, check sys_outbound_http_log for HTTP response codes, review the integration's business rule with logging enabled, and verify transform map field mappings against actual incoming data shape.

Outbound REST LogECC Queue StateTransform Map MappingAsync Business Rule

Get AI-Powered Diagnosis See Pricing

Symptoms

Incidents updated in ServiceNow but no corresponding update in the external system

sys_outbound_http_log showing 401, 403, or 5xx responses repeatedly

ECC queue entries with state='error' accumulating with no remediation

Some incident fields syncing while others don't (typically null values)

Sync working for new incidents but not for updates to existing ones

Integration logs showing 200 OK responses but the receiving system has no record

Root Causes

Outbound REST authentication expired

If the REST message uses basic auth with a service account whose password rotated, or OAuth where the refresh token expired, every outbound call returns 401. The messages stack in sys_rest_message with state='error' until the credential is updated.

Async business rule swallowing exceptions

Business rules marked as async run outside the user's transaction. Exceptions thrown in the script are logged to the script execution log but don't fail the original incident save — users see successful saves while the integration silently fails.

Transform map field mapping using null-incompatible coalesce

A transform map field that expects a non-null target on a field that's intermittently null in source data drops the entire row. ServiceNow logs this in sys_import_set_run but the user-facing experience is 'incident not synced'.

ECC queue stuck due to MID server connectivity

When ServiceNow uses a MID server for outbound integration (common with on-prem destinations), MID server disconnection puts the ECC queue entry in 'ready' state indefinitely. The integration never completes but doesn't fail either.

Field-level data type mismatch in REST payload

When the integration script constructs the REST body, a field type mismatch (sending a string for a number field in the target) returns a 422 from the target but the script doesn't check the response code — the message is marked 'sent' even though it was rejected.

How to Fix It — Step by Step

Check sys_outbound_http_log for HTTP errors

Filter sys_outbound_http_log by sys_created_on >= LAST_N_HOURS:24 and status_code != 200. This is the most efficient way to identify auth failures (401/403), target system errors (5xx), and validation failures (4xx).

Example

GET /api/now/table/sys_outbound_http_log?sysparm_query=status_code!=200^ORstatus_codeLIKE5&sysparm_fields=status_code,name,response_body,sys_created_on

Inspect sys_rest_message for stuck or errored messages

Navigate to System Web Services → Outbound → REST Messages. Filter by state=error or state=ready (stuck). For each, view Execution History to see the response body and error details.

Check ECC queue for MID server pending entries

Filter ecc_queue by state=ready and topic LIKE the integration's topic name. Entries older than the expected processing time indicate MID server connectivity issues or queue processing problems.

Example

GET /api/now/table/ecc_queue?sysparm_query=state=ready^topicLIKEIntegration&sysparm_fields=sys_created_on,topic,name,state,error_string

Rotate credentials and update REST message

If auth is the issue, update the credential record (System OAuth → Credentials, or in the REST Message's HTTP Headers). For OAuth, re-authorize the connection. Test with the 'Test' button on the REST message before re-running queued messages.

Enable verbose logging on async business rules

Edit the integration business rule and add gs.info() logging at every branch. For async rules, exceptions don't propagate — explicit logging is the only way to see what failed. Use gs.error() in catch blocks to log to the system log at error level.

Example

// In the business rule script
try {
  var r = new sn_ws.RESTMessageV2('Incident_Sync', 'POST');
  r.setStringParameterNoEscape('incident_number', current.number);
  var response = r.execute();
  var responseBody = response.getBody();
  var statusCode = response.getStatusCode();
  gs.info('Sync result: ' + statusCode + ' - ' + responseBody);
  if (statusCode >= 400) gs.error('Sync failed: ' + statusCode);
} catch (e) {
  gs.error('Sync exception: ' + e.message);
}

Audit transform map field mappings against source data

For each transform map field, check the source field's actual null rate. If 5% of source rows have a null in a mapped-to-required-target field, you're losing 5% of incident syncs. Either add a default value coalesce in the transform script or make the target field nullable.

Re-queue failed messages after fixing root cause

After fixing auth or mapping issues, re-process the stuck messages. For sys_rest_message, click 'Re-send'. For ECC queue, set state='ready' on the error entries. For transform map failures, re-run the import set.

Let BuildForce diagnose and fix this automatically

Instead of following manual steps, connect your org and let our AI identify exactly what's broken and how to fix it — in minutes.

Book a Demo

Common Questions

More answers about this issue and how to resolve it.

Stop debugging manually. Let AI do it.

BuildForce runs 200+ automated checks across your Salesforce org and tells you exactly what's broken and how to fix it.

Book a Demo View Pricing