Skip to main content

ServiceNow Troubleshooting

Retry behavior

When BigPanda pushes an incident to ServiceNow, it POSTs to the import set endpoint /api/now/import/x_bip_panda_shareincident. Each request is subject to a 20-second timeout and is retried automatically up to twice.

Requests that are retried

A request is retried automatically when ServiceNow returns one of the following:

  • HTTP 502, 503, 504, 521, 522, or 524.

  • A connection-level error: ECONNRESET, ECONNREFUSED, EPIPE, ENETUNREACH, or EAI_AGAIN.

Failures that are not retried

All other responses, including 401, 403, 404, and 429, are treated as final for that incident share and are not resent.

The retry set is deliberately narrow. Because incidents are submitted through a ServiceNow import set endpoint, resending a request whose outcome is unknown risks creating a duplicate record. BigPanda retries only where a failure is unambiguously transient and the request is unlikely to have been processed.All other responses, including 401, 403, 404, and 429, are treated as final for that incident share and are not resent.

The retry set is deliberately narrow. Because incidents are submitted through a ServiceNow import set endpoint, resending a request whose outcome is unknown risks creating a duplicate record. BigPanda retries only where a failure is unambiguously transient and the request is unlikely to have been processed.

Success is not just HTTP code

A successful HTTP response does not on its own mean the incident was created. BigPanda inspects the import set result rows returned by ServiceNow. If a row failed to transform, for example because a business rule aborted the insert, BigPanda reports that error message back in the same way as a failed request.

This means a transform or business rule problem in your ServiceNow instance surfaces in BigPanda rather than failing silently.

CMDB tables from plugins or custom CMDB tables are not syncing

If you configure a CMDB table that is not one of the tables shipped in the BigPanda application's out-of-the-box configuration. For example, a custom CMDB table or a CMDB table installed by another ServiceNow plugin, the sync may return no records even though the table contains data.

As of v3, the BigPanda application runs in a scoped application (x_bip_panda). To meet ServiceNow Store security requirements, the previous blanket "global CMDB read" grant was removed. For any table outside the BigPanda scope, you must explicitly grant the BigPanda application cross-scope read access to that table before records can be synced.

To grant cross-scope read access for a CMDB table:

  1. In the filter navigator, enter Application Cross-Scope Access and open the list.

  2. In the application scope picker, switch to the BigPanda scope.

  3. Click New and enter the following values:

    Field

    Value

    Source Scope

    BigPanda

    Application

    BigPanda

    Target Scope

    Global (or the scope that owns the table)

    Target Name

    The name of the CMDB table, for examplecmdb_ci_server

    Target Type

    Table

    Operation

    Read

    Status

    Allowed

  4. ClickSubmit.

  5. Re-run the CMDB sync from BigPanda > Admin > Configuration > CMDB and confirm that records now appear.

This applies to any CMDB table that is not part of the default OOTB table configurations, including plugin-installed CMDB tables and custom CMDB tables. For reference, you can open the existing cross-scope access records for the OOTB tables that ship with the BigPanda app.

Incidents, sync, or configuration values are behaving unexpectedly

The x-bp-config-org-id custom HTTP header is required on the BigPanda ServiceNow integration webhook. Its value must match the name of the BigPanda org record you created in ServiceNow during Step 5 of the install.

If the header is missing, the integration cannot determine which x_bip_panda_config record to load. This can surface as a range of quirky symptoms, including incidents not being created, credentials appearing to be unset, configuration changes not applying, and sync operations running with defaults instead of the configured values.

If you see unexplained behavior in incident sync, tag mapping, or webhook delivery, confirm the webhook is sending x-bp-config-org-id with the correct org name before investigating further.

In this section: