For teams that track infrastructure work in a Jira Software or Jira Core project rather than a service desk: when SmartTile opens a device ticket, it also creates an issue in your project — with the device, the site and the SmartChoice ticket number already written in.
POST /rest/api/2/issue, signed in with an Atlassian account e-mail + API token. Not a service desk: for Jira Service Management use the JSM connector.Not every IT team runs a service desk. Many plan their infrastructure work on a Jira board, and an outage that only lives in a monitoring e-mail never makes it onto the board. This connector puts it there: the outage becomes a Jira issue in the project you name, created by SmartTile the moment it opens its own ticket for the device.
One issue per outage in your project key and issue type (Task unless you name another — Bug, Story…). Summary and description come from the same template as the SmartChoice ticket: device, location, sibling devices and site contacts.
The per-device open a ticket after timer (15 minutes platform default) and the per-platform open delay in the Ticket Policy both apply — a blip shorter than the delay creates nothing. A snoozed device creates nothing.
SmartTile remembers the open issue key per device and will not create a second while it is open. When several devices at one site drop together, the later ones are recorded against the first issue instead of opening their own.
When SmartChoice's Rev.io ticket is opened first, its number is appended to the issue summary and a line in the description says SmartChoice is working the outage with the carrier.
Set a Webhook URL (and optional bearer token) instead of an API token and SmartTile POSTs vendor, subject, description, note to it — for teams that build the issue with their own Jira automation rule.
Every issue created is a row in the Automation Audit Ledger (DeviceAutomate → vendor ticket), scoped to the viewer's companies, with the issue key.
[TEST] SmartTile jira connectivity issue and shows its key — delete it afterwards.| Field | What goes in it |
|---|---|
| Base URL | https://yourco.atlassian.net |
| The Atlassian account the token belongs to | |
| API Token | From id.atlassian.com; stored encrypted |
| Project Key | e.g. NET — required |
| Issue Type | Task by default; exact name |
| Webhook URL / Token | Optional — replaces the API call |
Issue type: Task · Project: NET
Device: FG-60F Head Office · Location: Head Office
Other devices at the site and the site contacts, from the ticket template
SmartChoice Rev.IO ticket #83421 — SmartChoice (your provider) is working this outage with the carrier.
/rest/api/2/issueCreate the issue — project key, summary, description, issue type. Basic auth, e-mail:API token.<your webhook URL>Only if a Webhook URL is set — instead of the call aboveThe Jira settings, token included, are stored as one encrypted blob (cryptoVault) and come back to the screen masked.
The settings and the Test button sit behind the admin / super-admin gate of the ticketing API.
Untick Enabled and SmartTile stops creating Jira issues on the next outage; nothing else in Jira is touched.
| Question | Answer |
|---|---|
| “Will it close the issue when the site is back?” | No. Jira Core is create-only; recovery leaves the issue open for your team, and SmartTile keeps it marked open rather than pretend it closed. |
| “Do notes flow both ways?” | No. SmartTile neither comments on nor reads comments from Jira Core issues. If you need notes both ways, status sync and auto-close, use the Jira Service Management connector. |
| “Data Center?” | Built and tested for Jira Cloud. A Data Center site that accepts e-mail + token Basic auth on REST v2 may work, but it is not claimed. |
| “Priority, labels, assignee?” | Not set — the issue takes your project's defaults. |
| “Why BETA?” | The create path is built; no company runs it in production yet. We prove it on your project with the Test button first. |