Create a ServiceNow instance

An Instance (also called a Workflow) is the named delivery target that tells Data Out where to send a ServiceNow incident. Each ServiceNow instance ties together:

• A Connection (which ServiceNow instance + which service account)
• A Data in ServiceNow integration (optional - links the incidents Data Out creates to the incident data JupiterOne already ingests)

Unlike a Jira instance, a ServiceNow instance has no project or issue type to choose. ServiceNow Data Out always creates records in the Incident table, so there is nothing else to configure on the instance itself.

You can create as many instances per connection as you need - for example, one per team so each team's tickets are easy to find by name.

Prerequisites

• At least one Connected ServiceNow connection. See Configure a ServiceNow connection if you have not authorized one yet
• (Recommended) A ServiceNow Data in integration that already ingests your incidents. This lets JupiterOne reconcile the incidents Data Out creates with the incidents the integration ingests, so you do not end up with duplicates. If you skip this, the field defaults to None and you can still create an instance. See Add an integration and the ServiceNow integration for setting up data ingestion

Open the Add ServiceNow instance wizard

You can start the wizard from two places:

• Provider detail page - open Data out > Connections > ServiceNow. On a connection card with no instances yet, click Add an instance. Once the card lists instances, click + Add instance above its table. Either way, this pre-selects the connection so the wizard skips Step 1
• Instances tab - open Data out > Instances, find the ServiceNow section, and click + Add instance in the section's toolbar, next to the status filter. This opens the wizard at Step 1 so you can choose which connection to use. The ServiceNow section appears here only after at least one ServiceNow instance exists, so create your first instance from the provider detail page

The Add ServiceNow instance wizard is a three-step Stepper modal: Select Connection -> Configure -> Test.

Step 1 - Select Connection

Choose which ServiceNow connection this instance should use. The step lists every ServiceNow connection in your workspace with its status badge (Connected or Failed).

• Click a card to select it - the selected card gets a blue outline
• Click Next to advance. Next stays disabled until you select a connection

If you do not have any ServiceNow connections yet, the step shows No connections - Add a connection before creating an instance. Follow Configure a ServiceNow connection first.

info

If you started the wizard from a connection card's Add instance button (rather than from the global Instances tab), the wizard auto-selects that connection and starts at Step 2 instead. You can always go back to Step 1 from the Stepper if you change your mind.

Step 2 - Configure

Configure names the instance and, optionally, links it to a Data in integration.

Field	What to enter
Workflow name	A friendly label for this instance, for example ServiceNow Incidents - Security Operations. The name is what admins see in the Instances tab and what producers (like the CCM Create ticket modal) use to identify the routing target. Because a ServiceNow instance has no project or issue type to put in the name, pick something that tells people where the incident will land - for example, the team or assignment queue that handles it in ServiceNow.
Data in ServiceNow integration	Optional. Dropdown of existing Data in ServiceNow integrations in this workspace, each with its latest job status. Selecting one lets JupiterOne sync the incidents Data Out creates with the data that integration ingests. Defaults to None.

tip

If the Data in ServiceNow integration field does not appear, or does not list the integration you expect, you have not yet set up a ServiceNow Data in integration in this workspace. See Add an integration. You can still create the instance without one.

Click Create workflow to create the instance and continue to Test. Click Back to change the connection (when you started from Step 1), or Cancel to close the wizard without creating anything.

Step 3 - Test

The Test step lets you fire a real ServiceNow incident through the instance you just created, so you can confirm the round-trip works before relying on the integration. The instance already exists at this point - the Test step is purely a validation gate.

Field	What to enter
Short description	The incident Short description field. The field starts empty with an example placeholder (Investigate failing control), so type your own text. JupiterOne automatically adds a [TEST] prefix when it sends the payload, so the incident is easy to recognise in ServiceNow (for example, [TEST] Investigate failing control).
Description	The incident Description field, sent as plain text. The field starts empty with a placeholder, so type a short note such as Testing JupiterOne Data Out.

You have two terminal actions:

• Send test posts the test payload to your ServiceNow instance. A new incident appears in ServiceNow shortly after. Use this for the first instance you stand up so you have a known-good baseline. Remember to close or delete the test incident in ServiceNow afterward to keep your queue clean
• Finish closes the wizard without sending a test payload. Use this if you have already validated this connection and just need a second instance pointing at the same ServiceNow instance

When a test succeeds, the wizard shows Test successful! The workflow received your payload. and The record is being created and will appear in ServiceNow shortly. The Send test button is replaced by Finish.

Either way, the instance is now Active and visible on the Instances tab.

For a deeper walkthrough of how to interpret a successful or failing test, see Test your ServiceNow instance.

After you create the instance: where to find it

The new instance appears in three places:

• Provider detail page (Data out > Connections > ServiceNow) - in the connection card's instance table, with columns Instance / Status / Last run / Successful jobs / Failed jobs
• Instances tab (Data out > Instances) - the same table, grouped by provider with N instances / N active badges
• Instance detail page - click the instance name in either of the above tables to open the per-instance detail view (Status, Last run, Last updated, Lifetime tasks, Jobs succeeded, Jobs failed, Data in integration, plus the per-instance Jobs table). See Manage instances for what you can do from there

Unlike Jira instances, ServiceNow instances do not show a Project issue type column, because there is no project or issue type to display.

What happens in JupiterOne when an incident is created

Each time someone creates a ticket through a ServiceNow instance, JupiterOne records the result in your graph so the incident stays traceable from the thing it was raised for:

• A service_now_incident entity is created, using the ServiceNow incident number (for example, INC0010001) as its name, with a webLink to the incident in ServiceNow
• A HAS relationship connects the entity the ticket was raised for (for example, a CCM control) to the new incident
• JupiterOne polls ServiceNow for updates to those incidents and mirrors whether each one is still open, so the active property on the entity follows the incident's lifecycle. Because this is polling rather than a real-time push, a change in ServiceNow can take some time to appear in JupiterOne

To list the incidents in your account, run a J1QL query such as:

FIND service_now_incident AS i RETURN i.displayName AS incident, i.active AS active, i.webLink AS link LIMIT 50

Use an instance for organizational unit routing

Every ServiceNow and Jira instance is also selectable as a Ticketing workflow on an organizational unit (OU) and as the Default ticketing workflow on an OU namespace, under Settings > Organizational Units. This is how vulnerability case tickets are routed to the team that owns the affected asset. See Ticketing workflows and routing.

note

An OU's Owner email pre-fills the ticket assignee for Jira instances only. ServiceNow incidents created from the Create ticket modal are created without an assignee, so route them using ServiceNow assignment rules or your triage process.

What is not configured on the instance

The only fields stored on a ServiceNow instance are the two on the Configure step (Workflow name and Data in ServiceNow integration). In particular:

• Table - fixed to Incident. You cannot choose another table, such as Change Request or Problem
• Templates - ServiceNow record templates are not supported
• Per-incident fields - Short description and Description are entered at the moment a ticket is created, either by the producer (such as the CCM Create ticket modal) or by the test payload above. Other incident fields, such as Assignee, Assignment group, Caller, Category, Urgency, and Impact, are not set by Data Out in this release
• Field mapping - there is no per-field mapping editor or templated default configuration on the instance

If your ServiceNow instance requires additional fields on new incidents - through a mandatory-field data policy, for example - or sets them with business rules, apply defaults on the ServiceNow side. See Troubleshoot ServiceNow Data Out if incident creation is being rejected.