Skip to main content

Test your ServiceNow instance

Sending a test payload through a new instance is the fastest way to confirm everything is wired correctly: the connection has the right credentials, the service account can create incidents, and JupiterOne can write to your ServiceNow instance. We strongly recommend running a test on every instance before you let it serve real CCM tickets.

When to test​

  • Right after creating an instance - the Add ServiceNow instance wizard ends on a Test step for exactly this reason
  • After re-authorizing a connection - to confirm the new password still has write access to incidents
  • After changing ServiceNow roles, access controls, or incident rules - to catch breakage before a real CCM ticket fails. Examples include a new mandatory field on incidents, or a change to the service account's roles

Test from the wizard​

The cleanest test path is the Test step of the Add ServiceNow instance wizard. It walks you through Short description and Description, posts a real incident, and lets you confirm in ServiceNow immediately.

FieldDefaultWhat to do
Short descriptionEmpty (placeholder: Investigate failing control)Enter something distinctive so the incident is easy to find in ServiceNow, for example J1 Data Out test - 2026-10-27. JupiterOne adds a [TEST] prefix for you, so the incident arrives as [TEST] J1 Data Out test - 2026-10-27. The prefix is never doubled if you type it yourself.
DescriptionEmpty (placeholder: Details...)Add any context you want included in the incident body. It is sent as plain text.

Click Send test to fire the payload at your ServiceNow instance. After Send:

  • The wizard shows Test successful! The workflow received your payload. and The record is being created and will appear in ServiceNow shortly.
  • A new incident appears in ServiceNow in the Incident table, with the Short description and Description you entered
  • Open the incident in ServiceNow and confirm the Short description and Description landed as expected
  • Close or delete the test incident in ServiceNow once you have verified - the [TEST] prefix makes test incidents easy to find, and leaving them open can distort queue metrics and trigger downstream notifications
info

Test successful means JupiterOne accepted the request and handed it to the instance's automation. ServiceNow creates the incident moments later, so if it does not appear, check the instance's Jobs table as described below.

If you do not need to send a test (for example, you just verified an identical instance using the same connection), click Finish to close the wizard without sending.

What success looks like​

When the test succeeds, two surfaces update:

  • The instance row's Successful jobs count on the Instances tab (and on the connection card's instance table on the provider detail page) increments by 1
  • The instance's Last run timestamp updates to "just now"

You can also open the instance detail page and find the test job at the top of the per-instance Jobs table with status Succeeded. See Manage instances.

What failure looks like​

If the wizard shows The test request failed. Please check your connection and try again. or Something went wrong. Please try again later., the payload was not delivered. If the wizard reports success but the incident never appears, ServiceNow rejected it after hand-off. In that case, the Failed jobs count on the instance row increments by 1 and the Last run timestamp shows the failure time. The instance stays Active - a single failed job does not deactivate the instance.

To see the error message:

  1. Click the instance name to open the instance detail page
  2. The most recent job appears at the top of the Jobs table with status Failed and an Error message column
  3. Common causes:
    • Authentication failure - the service account's password changed or expired, the account was locked, or Password needs reset was set. Connection-level recovery is documented at Re-authorize a connection
    • Access denied on the Incident table - the service account can sign in but lacks permission to create incidents. Ask your ServiceNow administrator to grant the access listed under Grant the account the access it needs
    • Basic authentication blocked - your ServiceNow instance restricts basic authentication for API calls and the account is not exempt. See Check your instance's authentication settings
    • Instance unavailable - the ServiceNow instance is offline, hibernating (common for developer instances), or being upgraded. Wake or wait for the instance, then send the test again
    • A required field is missing - your ServiceNow instance requires a field on incidents, such as Caller or Category, through a data policy or business rule, and Data Out sends only Short description and Description. Set defaults for that field on the ServiceNow side, or relax the rule for the service account

For a fuller list of failure modes, see Troubleshoot ServiceNow Data Out.

Re-running a test on an existing instance​

The wizard's Test step is the only dedicated test surface. To re-test an existing instance:

  1. Open Data out > Connections > ServiceNow and add a temporary instance on the same connection with Add instance, then use Send test on its Test step. Delete the temporary instance when you are done. See Manage instances
  2. Or, create a real ticket from a non-critical failing control through the CCM Create ticket flow, then watch the Successful jobs and Failed jobs counts on the instance row

If you changed the connection credentials, remember that existing instances use the updated credentials automatically - you only need to re-test to confirm the new credentials work end to end.

Contents