Ticket sources
Connecting HubSpot, Zendesk, Jira or your own forms as the inbox, which credential each one takes, what to do when the deployment is self-hosted, and the Resend channel replies go back out through.
A ticket source is where the inbox comes from. Integrations let the agent read your systems; a ticket source is the thing it is reading about.
Each source is configured on the desktop Integrations page, under Ticket sources. Ingest is webhook-first with a poller behind it, so a source works with only the credential filled in. The webhook secret makes it immediate rather than every two minutes.
Saving runs a connection test. If it fails you can still Save anyway, which is what you want when the failure is a network detail you are about to fix.
Any org member can connect a source
Ticket sources are not admin-only: any signed-in member of the organization can connect, edit or remove one from their desktop app, and it applies to their own organization only. Every change is written to the audit log with the member who made it.
HubSpot
| Field | Required | What to put |
|---|---|---|
| Access token | yes | A private app token (Settings → Integrations → Private apps) or an OAuth access token from your own HubSpot app. Both work in this one field. It needs the tickets read scope. |
| Webhook secret | no | The app's client secret. Leave it empty for a poll-only setup; without it, inbound webhooks are rejected. |
| API base path | no | Empty for api.hubapi.com. Point it at a mock server for testing. |
A private app token and an OAuth token are the same credential
HubSpot implements private app tokens on top of OAuth, and both are sent as
Authorization: Bearer. There is no second field to pick between them because there is
nothing on the wire to distinguish.
Zendesk
Pick the authentication method. The Authentication method select changes which fields appear; the other method's fields are hidden, are not required, and are dropped when you save.
- API token: agent email + token. What most existing connections use.
- OAuth access token. Prefer this for a new connection, for the reason below.
Create the credential.
API token: Admin Center → Apps and integrations → APIs → Zendesk API, then add
a token. It is sent as basic auth over {email}/token:{token} and carries the full
permissions of the agent account whose email you enter beside it.
OAuth access token: an access token issued by a Zendesk OAuth client in your
account (Admin Center → Apps and integrations → APIs → OAuth clients). Reading
tickets needs the read scope. Paste the access token itself, not the client secret.
An OAuth access token expires, and nothing here renews it
Triagic does not run the browser authorization flow, so the token you paste is the token it keeps using. The connector stops when that token expires.
Fill in the fields.
| Field | Required | What to put |
|---|---|---|
| Subdomain | yes | Just the subdomain: for https://acme.zendesk.com that is acme, not the URL. |
| Authentication method | no, defaults to API token | Which of the two above. |
| API token only | The agent account the token was created under. Its permissions are the ones this connector gets. | |
| API token | API token only | |
| OAuth access token | OAuth only | Sent as Authorization: Bearer. |
| Webhook secret | no | The webhook signing secret, shown once when you create the webhook. Without it, inbound webhooks are rejected and only the poller runs. |
Why OAuth is worth the extra step
Zendesk marks the API-token scheme deprecated, and its own warning says why: an API token can be used to impersonate anyone in the account. An OAuth token carries only the scopes it was granted. Both still work. This is a reason to choose, not a deadline.
Zendesk has no self-hosted product and every URL is built from the subdomain, so there is no host, CA-certificate or verify-TLS field on this form.
Jira
Jira Cloud and Jira Server / Data Center differ in more than the credential: they serve
different REST versions, and Data Center does not have the search endpoints Cloud added.
The Authentication method select is what tells Triagic which one it is talking to,
so a mismatch here fails at the first request with a 401.
Pick the deployment.
- Cloud: email + API token. An
*.atlassian.netsite. The default. - Server / Data Center: personal access token. Self-hosted. These instances cannot issue Atlassian API tokens at all, and take a bare bearer token with no email beside it.
Create the credential.
Cloud: an API token at id.atlassian.com → Security → API tokens. It acts as the Atlassian account it belongs to, so use an account whose project permissions are the ones you want.
Server / Data Center: a personal access token from the account's own profile, under Profile → Personal Access Tokens → Create token. Jira needs 8.14 or newer; older versions have no such screen. There is no email field to fill in: the token identifies its own owner and inherits that account's project permissions.
Fill in the fields.
| Field | Required | What to put |
|---|---|---|
| Base URL | yes | https://acme.atlassian.net for Cloud; whatever host serves your instance for Data Center, e.g. https://jira.acme.internal. |
| Authentication method | no, defaults to Cloud | Which deployment this is. |
| Cloud only | The Atlassian account the API token belongs to. | |
| API token | Cloud only | |
| Personal access token | Data Center only | Sent as Authorization: Bearer, with no email. |
| Webhook secret | no | HMAC secret for a system webhook, checked against X-Hub-Signature. |
| URL token | no | Fallback for instances that cannot sign: a shared token passed as ?token= on the webhook URL. |
| CA certificate path | no | A Data Center instance behind a private CA. An absolute path on the machine running Triagic to that CA's PEM bundle. It applies to this connector alone. |
| Verify TLS certificate | no, defaults on | Turn off only for a self-signed instance you cannot supply a CA bundle for. |
Configure one of the two webhook fields or neither. With neither, the connector falls back to polling: inbound webhooks are rejected, because an unauthenticated one cannot be attributed to your organization.
When something goes wrong
| If it reports | It usually means |
|---|---|
401 on a Data Center URL | The method is still set to Cloud. Data Center does not accept an email and API token at all. |
401 on an *.atlassian.net URL | The method is set to Data Center, or the token was created under a different account than the email names. |
HTTP 404 from search | The base URL is right but reaches something other than Jira. Check for a path prefix or a reverse proxy rewriting the request. |
| A certificate error rather than a Jira error | The instance's certificate is not trusted by that machine. Set CA certificate path, or turn off Verify TLS certificate. |
| A picker is empty but polling works | That lookup is not available on your Jira version. Use Raw JQL instead; it replaces every picker. |
Forms
The Forms card is your organization's own native forms, and it is the one source with nothing to fill in. There is no provider to authenticate against: this machine is already signed in to your Triagic account, and that is the connection. So the card has no Configure button, no credentials, no sync rules and no triage toggle. It shows the last sync, and Test connection, Sync now and Disable work as they do elsewhere.
Which submissions arrive is decided by the forms your organization publishes in the portal, not by anything here. The card does not list the forms, because this machine only ever sees the ones somebody has submitted recently; the portal has all of them with their links.
Filters
Every source carries filters below the connection fields, and they gate both paths: a webhook that does not match is dropped, exactly like a polled ticket that does not match. The one exception is Jira's Raw JQL escape hatch: it can express anything, so it is not re-implemented for webhooks, and a config that uses it leaves webhook ingest unfiltered.
Auto-triage
Each source card carries its own triage switch, Turn on triage / Pause triage,
with a triage on / triage off pill beside the connection status. It is off by
default: connecting a source starts ingest, not LLM investigations. Tickets still
arrive, get embedded and classified against your playbooks; nothing investigates them
until you switch triage on, and until then each one is investigated only when someone
hits Investigate now on it.
Pausing triage later leaves ingest running, which is the point: it stops the LLM spend on a source without disconnecting it or losing the tickets.
Every source that predates the switch comes out of the upgrade with triage on, because it was already triaging everything before the toggle existed and an upgrade must not silently stop that. Off-by-default applies to sources connected since. Read the pill on each card rather than assuming.
Only these configured sources have the switch
The toggle exists per source config, so it covers HubSpot, Zendesk, Jira and Thread. Slack, manually created and checkup-promoted tickets have no config row and always triage on arrival. Forms has a config row but no switch: its triage setting is per form, in the cloud portal, and it starts on. See Forms below.
Email (Resend)
Managed in the portal when your organization connects its own email
If an admin has set up Email in the portal, this row shows that connection, reads Managed in the Triagic portal, and cannot be edited here. The Resend key described below is the per-machine option for organizations that have not.
Below the sources on the same Ticket sources panel sits Email (Resend), the way answers get back out. It is what the Send email buttons on a ticket's suggested reply and on the Console answer bar send through; with nothing connected those dialogs say so and only let you copy the draft. See Emailing the customer for the send itself.
Two fields:
| Field | Required | What to put |
|---|---|---|
| Resend API key | yes | re_… from API Keys in the Resend dashboard, with sending access. |
| From address | yes | support@yourdomain.com, or Support <support@yourdomain.com>. The domain has to be verified in Resend. |
Saving probes the key against Resend before it stores anything, so a bad key fails at the form rather than at the first send. Disconnect removes it and the Send email buttons go back to disabled.
Admin-only, and one channel for the whole machine
Unlike the ticket sources above, this is an org-admin form: members see the connection status and "Managed by your organization admin" instead of the fields. There is one configuration per install, not one per member or per source: the same Resend key and From address are behind every send from this machine.