Share this page with your Jira admin before you set up the Jira integration. With these answers you can complete the Xyte wizard yourself.
What the integration does: every Xyte device incident creates a Jira Service Management request, keeps its summary and priority up to date, and moves it to a closing status when the Xyte incident is resolved. Optionally, changes made in Jira sync back to Xyte.
🚧Don't write the webhook secret into this questionnaire. Pass it on through a password manager.
| # | Question | Why Xyte needs it | Answer |
|---|
| 1.1 | Who is the Jira site admin for this project (name, email)? | They authorize Xyte and, optionally, create the webhook. | |
| 1.2 | Which team works the requests Xyte creates? | Decides the service desk and request type in section 3. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 2.1 | Is your Jira on Atlassian Cloud (<name>.atlassian.net)? | Only Jira Cloud is supported, not Data Center or Server. | |
| 2.2 | What is the site URL? Can the authorizing user grant Xyte access to that site only? | If the user grants several sites, Xyte connects to the first one with Jira Service Management, which may not be the right one. | |
| 2.3 | Does the site have both Jira and Jira Service Management? | Xyte needs Jira's write:jira-work scope to set priority. A JSM-only site shows Access denied at consent. | |
| 2.4 | Who will click Authorize access in Xyte? They need admin rights on the service desk and access to both products. | The OAuth connection runs as this user. | |
| 2.5 | Can that user approve a third-party OAuth app, or must an org admin allow it first? | Some Atlassian orgs block user-installed apps. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 3.1 | Which service desk (project) should requests go to? | Picked from a list in the Service Desk step. | |
| 3.2 | Which request type should Xyte use (e.g. "Report a device issue")? | Picked from a list in the Request types step. | |
| 3.3 | Does that request type's form include Summary and Description fields? Which form fields should hold them? | Set in Field mapping. The request type must accept Summary (and ideally Description), or requests can't be created with any text. | |
| 3.4 | Are other fields mandatory on that request type? | Xyte sends only summary, description and priority, so other fields must be optional or have a default. | |
| 3.5 | Do you want a custom summary or description (e.g. {title} - {priority} - {space_name})? | Set in Templates. A summary template is max 255 characters and re-applied on every update. While it's set, summary edits in Jira don't change the Xyte incident title. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 4.1 | Does the project use the standard priorities Highest, High, Medium, Low, Lowest? | Xyte maps Critical→Highest, High→High, Moderate→Medium, Low→Low, Planning→Lowest. These five names must exist in the project's priority scheme. If one is missing, Xyte's priority and summary updates to the request fail. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 5.1 | Should Xyte close the request when the incident is resolved, or should your team close it in Jira? | Pick a transition, or Do not automatically close, in Close status. | |
| 5.2 | Which transition closes a request? Can it run from any open status, and is it available on the request itself (not agent-only)? | Xyte lists the transitions Jira Service Management offers on a request. An agent-only transition may not appear, and one unavailable from the current status can't run. | |
| 5.3 | Does that transition show a screen with mandatory fields (e.g. Resolution)? | Mandatory screen fields block the automatic close. | |
| 5.4 | To list transitions, Xyte opens a test request titled Xyte Integration - Workflow Discovery — each time the request type is picked or the close-status list is reloaded. Who will close these? | Xyte doesn't close or delete them. The list shows transitions from the request type's first status. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 6.1 | Should changes in Jira (summary, description, priority, closing) update the Xyte incident? | Needs a Jira webhook. If no, skip this section. Summary edits sync back only when no summary template is set (3.5). | |
| 6.2 | Who has site-admin rights to create a webhook under Settings → System → WebHooks? | Only site admins can create webhooks. | |
| 6.3 | Should the webhook be limited by JQL to one project (e.g. project = SUP)? | Recommended on busy sites, so only relevant events are sent. | |
| 6.4 | Is the status that ends a request in the Done status category? | Only a move to a Done-category status closes the Xyte incident. | |
| 6.5 | Confirm the webhook secret is ready to hand over securely. | Entered in the Webhook step. | |
| # | Question | Why Xyte needs it | Answer |
|---|
| 7.1 | Should every Xyte incident create a request, 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. | |
| Wizard step | Answers |
|---|
| Authorization | 2.1–2.5 |
| Service Desk | 3.1 |
| Request types | 3.2 |
| Field mapping | 3.3 |
| Templates | 3.5 |
| Close status | 5.1–5.3 |
| Webhook | 6.1–6.5 |
| Filtering | 7.1 |
| Enable | — |
Next: follow the Jira setup guide.
