What it does#
AckNexa opens a ticket for an incident in Jira Cloud, Jira Server / Data Center, or Halo (HaloITSM / HaloPSA), links it from the incident, mirrors acknowledgements, notes, stakeholder and status page updates, reassignment and the resolution as comments, and can move the ticket to its resolved state. There is one ticket per incident per tool, never one per alert.
Connect a tool#
| Tool | URL | Credentials |
|---|---|---|
| Jira Cloud | https://SITE.atlassian.net | The integration account's email and an API token. |
| Jira Server / Data Center | Your Jira base URL | A personal access token for the integration account, or username and password. |
| Halo | Your Halo instance URL | An API application with the Client ID and Secret (Services) login type and permission to create tickets and actions. |
Open Ticketing under Configure as an organization administrator and add a connection. Credentials are write-only and stored encrypted with ACKNEXA_CONFIG_KEY. Test connection signs in and loads the projects, issue types, ticket types, priorities and statuses the account can see, so rules are picked from lists. The account needs permission to create issues or tickets, add comments and, for the resolve action, transition them.
Rules per team#
Add one rule per team; a rule on a single service overrides its team's. A rule chooses the connection, the Jira project and issue type or the Halo ticket type, optional Jira components and labels or Halo team, agent, client and category, a priority per severity, the transition or status to apply on resolve, and whether to mirror comments.
It also chooses when to open the ticket: only when a responder asks, when the incident opens, or when it is acknowledged, from a minimum severity. Teams without a rule get no automatic tickets, but anyone who can acknowledge an incident can still open one with Create ticket, using the connection's defaults.
Ticket closure flowing back#
By default, closing a ticket changes nothing in AckNexa. Tick Sync ticket closure on the connection to get a webhook URL, shown once, and configure that URL in Jira (an Issue updated webhook) or Halo (a ticket status-change webhook). Then tick Resolve the incident when the ticket is closed on the rule (default off).
When a linked ticket reaches a closed state, the incident timeline always records it, and if the rule opted in, the system resolves the incident with the ticket as the reason, cancelling escalation and pending notifications. The webhook is idempotent and does not loop with the outbound sync. It only affects incidents that have a ticket on that connection.
Security and network#
- The webhook token is a random value stored only as a hash; a wrong token, a disabled webhook and an unknown connection all get the same 401. Senders that can set headers can send the token in X-AckNexa-Token or a bearer header instead of the path; the query string is never accepted.
- Because the path form is part of the URL, keep reverse-proxy access logs for /v1/ticketing/inbound/ off or redacted.
- AckNexa needs outbound HTTPS from the API and worker to the tool. TICKETING_HOSTS limits the hosts a connection may use, and TICKETING_ALLOW_HTTP=true permits http:// for an internal Jira on a trusted network.
- The tool needs to reach the API only if Sync ticket closure is on.
- Failed creation and comments are retried with backoff; credential and configuration errors stop at once and are reported on the incident timeline.