ServiceNow questionnaire

Share this page with your ServiceNow admin before you set up the ServiceNow integration. With these answers you can complete the Xyte wizard yourself.

What the integration does: every Xyte device incident creates a ServiceNow Incident, keeps its short description and priority up to date, and resolves it when the Xyte incident is resolved. Optionally, changes made in ServiceNow sync back to Xyte.

🚧
Hand over secrets securely
Don't write passwords or client secrets into this questionnaire. Confirm they exist here, and pass them on through a password manager.

1. Owners

#	Question	Why Xyte needs it
1.1	Who is the ServiceNow admin for this project (name, email)?	They create the service account, OAuth app and, optionally, the Business Rule.
1.2	Who receives the incidents Xyte creates (team or assignment group)?	Decides the field values in section 4.
1.3	Do you need a change request to add a service account or Business Rule? If yes, how long does approval take?	Plan the timeline.

2. Instance

#	Question	Why Xyte needs it
2.1	What is the full instance URL? (e.g. `https://acme.service-now.com`, no trailing slash)	Entered in the Instance & Method step.
2.2	Which ServiceNow release is the instance on (e.g. Washington DC, Xanadu)?	The Client Credentials method needs Washington DC or newer.
2.3	Should Xyte be tested on a sub-production instance first? If yes, its URL.	You can connect the test instance first, then switch.
2.4	Does the instance restrict inbound API calls by IP address?	If yes, contact [email protected] before setup.

3. Access

#	Question	Why Xyte needs it
3.1	Which authentication method will you use: OAuth – Client Credentials (no password shared, Washington DC+), OAuth – password grant, or Basic (username + password)?	Determines which credentials are needed. See Authentication methods.
3.2	Has a dedicated service account been created (not a personal login)? What is its username?	Incidents are created as this user.
3.3	Does the service account have read/write on the Incident table (typically the `itil` role)?	Needed to create, update and resolve incidents.
3.4	Can the service account read the `sys_dictionary` and `sys_choice` tables?	`sys_dictionary` lets the wizard list your real field names (without it, field mapping is free text). `sys_choice` lets Xyte pick a valid resolution code when resolving.
3.5	OAuth only: has an OAuth API endpoint for external clients been created, and is its Scope Restriction set to Broadly scoped?	An endpoint-scoped app gets 403 from the Table API.
3.6	Client Credentials only: is the property `glide.oauth.inbound.client.credential.grant_type.enabled` set to true, and is the service account set as the OAuth Application User?	Without both, token requests fail with 401.
3.7	Basic or password grant: can the service account log in with a local password (not SSO-only)?	SSO-only accounts can't authenticate over the API.
3.8	Confirm the Client ID, Client Secret and/or password are ready to hand over securely.	Entered in the wizard's Credentials step.

4. Incident fields

#	Question	Why Xyte needs it
4.1	Which Incident fields are mandatory on creation in your instance (e.g. Caller, Category, Assignment group, custom `u_` fields)?	Each one needs a value in Field Mapping, or ServiceNow rejects the incident.
4.2	For each field in 4.1: what value should Xyte set? A fixed value (e.g. `category = hardware`) or a Xyte value (device name, serial, space…)?	Becomes one Field Mapping row.
4.3	Which user should appear as Caller?	Usually the service account or a shared "Xyte" user.
4.4	Any optional fields you want filled (configuration item, location, service…)?	Added as extra mapping rows.
4.5	Do you want a custom short description or description (e.g. `{title} - {priority} - {space_name}`)?	Set in Templates. Leave blank for Xyte's default. See available keys.

5. Priority

#	Question	Why Xyte needs it	Answer
5.1	Do you use the standard Impact × Urgency → Priority matrix?	Xyte sets Impact and Urgency, and ServiceNow derives the priority.
5.2	Which Impact (1–3) and Urgency (1–3) should each Xyte priority map to: Critical, High, Moderate, Low, Planning?	Set in Priority mapping. Defaults are provided if you skip it.

6. Resolving incidents

#	Question	Why Xyte needs it	Answer
6.1	Xyte resolves incidents by setting State = Resolved, a resolution code (Solution provided when available, otherwise the first valid code) and close notes. Are any other fields mandatory on resolve (data policies, UI policies, business rules)?	Extra mandatory fields block the resolve. Give them a value through Field Mapping, or relax the rule for the service account.
6.2	Does a Resolved incident auto-close after a set time, or does someone close it manually?	Confirms the lifecycle after Xyte resolves.

7. Two-way sync (optional)

#	Question	Why Xyte needs it
7.1	Should changes made in ServiceNow (short description, priority, resolve/close) flow back to Xyte?	Needs a Business Rule. If no, skip this section.
7.2	Who can create a Business Rule on the Incident table (after insert/update, with an advanced script)?	Xyte's wizard gives a ready-to-paste script.
7.3	Can the instance make outbound HTTPS calls to the Xyte webhook URL shown in the wizard?	The Business Rule posts to Xyte's webhook.
7.4	Will the rule be limited with the condition Correlation display is Xyte?	Only incidents Xyte created are sent. Without it, every incident change is posted.

8. Scope

#	Question	Why Xyte needs it	Answer
8.1	Should every Xyte incident create a ServiceNow incident, or only those at or above a minimum priority? Xyte's order is Critical > High > Moderate > Low > Planning, so a minimum of High sends High and Critical.	Set in Filtering.
8.2	Roughly how many devices and incidents per day do you expect?	Helps your team plan queue load.

Where the answers go in Xyte

Wizard step	Answers
Instance & Method	2.1, 3.1
Credentials	3.2, 3.8
Field Mapping	4.1–4.4, 6.1
Templates	4.5
Priority mapping	5.2
Two-way sync	7.1–7.4
Filtering	8.1
Enable	—

Next: follow the ServiceNow setup guide.