Operating
Ticketing integrations
One page per system, with the limitations published rather than discovered.
WHY THIS PAGE IS BLUNT
A documented limitation is a spec. An undocumented one is a bug report, usually filed in week six by somebody who has already told their boss it works.
Zendesk
| Capability | Supported | Notes |
|---|---|---|
| Inbound webhooks | Yes | Requires the Admin role to register. Falls back to 60s polling without it. |
| Writeback — comments | Yes | Public and internal comments. |
| Writeback — status | Yes | Solved and Pending. |
| Custom fields | Yes | Read and write. |
| KB article generation | Yes | Drafts into Guide as unpublished. |
| CMDB / asset correlation | No | Zendesk has no native CMDB. Use a custom field for the asset tag. |
Least-privilege setup
- 01Create a dedicated agent account, not a personal admin login. Name it svc-kestrel so it is obvious in the audit trail.
- 02Assign a custom role: ticket read/write on the target view only, comment add, status change to Solved, no user or organisation management, no settings access.
- 03Generate an OAuth client, or an API token if OAuth is unavailable in your plan.
- 04In Kestrel, scope to a single view. Widen later.
Known limitations
- Side conversations are not read. If your techs use them for the actual diagnosis, Kestrel will not see it.
- Zendesk rate limits are per-account, not per-token — a busy integration elsewhere in your instance reduces our headroom. We surface remaining headroom on the connector page.
- Ticket merges are detected on the next poll, not by webhook. A merge can produce one duplicate diagnosis.
ServiceNow
| Capability | Supported | Notes |
|---|---|---|
| Inbound webhooks | Partial | Requires web_service_admin. Most customers cannot get it; we poll every 60s instead and say so on the connector page. |
| Writeback — work notes | Yes | |
| Writeback — customer comments | Depends | Blocked by business rules in many instances. The connection test detects this. |
| Writeback — status | Partial | Resolved is supported. Closed usually is not — most instances require a manual close. |
| Custom fields | Yes | Including u_ fields. |
| CMDB correlation | Yes | This is ServiceNow’s real advantage. Use the CI reference; it produces the best correlation rates we see. |
Known limitations
- Custom business rules can silently reject writes. The connection test exercises a real write and reports the rule name that blocked it.
- Instances with heavy customisation of the incident table often need explicit field mapping. Budget an hour for this, once.
- Scoped applications are not supported. Kestrel operates in the global scope against the incident table.
Freshservice, Jira Service Management, ConnectWise
| System | Webhooks | Writeback | Custom fields | KB | CMDB |
|---|---|---|---|---|---|
| Freshservice | Yes | Yes | No | No | No |
| Jira Service Management | Yes | Yes | Yes | No | No |
| ConnectWise | No — polling only | Yes | No | No | No |
These three are supported and in production with design partners, but with narrower capability than Zendesk and ServiceNow. We publish the difference rather than averaging it into a uniform grid.
Device correlation
The hard part nobody expects. A ticket says “my laptop is broken” and Kestrel has to know which machine. Strategies, in the order we recommend trying them:
- 01CMDB CI reference — best when available. ServiceNow only.
- 02Asset tag custom field — nearly as good, and available everywhere. Worth adding a field for.
- 03Requester primary device — good for single-device users, poor for shared machines and kiosks.
- 04Hostname in the ticket body — works surprisingly often, because techs paste it.
- 05Ask the user — a fallback that posts a comment. Use it; a 15-second question beats a wrong machine.
Your match rate is computed against your last 100 real tickets and shown during setup, before you finish. A 40% rate means the product barely works, and you need to know that on day one rather than in month two.