Skip to main content
This guide walks you through connecting your Halo (HaloPSA / HaloITSM) instance to Clarion. Once connected, Clarion agents can call Halo’s REST API on your behalf to look up existing tickets, open new ones, update and close them, and add comments as part of an investigation.
Estimated time: 5 minutes. You will need Halo administrator access to register an API application.

​
Prerequisites

  • A Halo instance and administrator access to Configuration → Integrations → Halo API
  • The ability to create a Client Credentials application in Halo
  • A Clarion workspace with the Halo integration page open

​
Step 1 — Register a Client Credentials application in Halo

  1. Sign in to Halo as an administrator.
  2. Go to Configuration → Integrations → Halo API.
  3. Select Authorise a new application.
  4. Choose Client Credentials as the authentication method.
  5. Copy the generated Client ID and Client Secret.
Copy the Client Secret immediately and store it securely — Halo may only show it once. Consider using a dedicated service application rather than one tied to a personal account.
  1. On the application’s Permissions tab, grant the permissions needed to read and create tickets (for example, the ticket read/write scopes, or all).
  2. If you use a hosted Halo solution, note your Tenant identifier and your Authorisation server URL from the same Halo API page — you may need them in the next step.

​
Step 2 — Enter credentials in Clarion

  1. In Clarion, open Integrations and find Halo (HaloPSA) under Development & Planning.
  2. Enter your Halo URL — your web-app base address, e.g. https://acme.halopsa.com. Clarion derives the REST API (/api) and authorisation server (/auth) from it.
  3. Paste the Client ID and Client Secret from Halo.
  4. Hosted solutions only: enter your Tenant, and an Authorisation server URL if it differs from your Halo URL.
  5. Click Connect.
Clarion verifies the credentials by requesting an access token and making a lightweight ticket query before saving. If the credentials or URL are wrong, you’ll see a clear error and nothing is persisted.

​
Step 3 — Ingest tickets with a Halo monitor (optional)

Steps 1 and 2 let agents act on Halo. This step lets Halo start the work: a webhook sends tickets to Clarion, and filters you control decide which of them an agent triages. Add the monitor.
  1. In Clarion, open Integrations → Halo (HaloPSA) → Monitors and click Add Monitor.
  2. Pick Halo. Clarion generates a webhook URL and a one-time password — copy both now, the password is not shown again.
Add the webhook in Halo.
  1. Go to Configuration → Integrations → Webhooks and create a new webhook.
  2. Set Webhook type to Standard webhook, Method to POST, and paste the Clarion URL as the Payload URL.
  3. Set Authentication to Basic Authentication, with the username clarion and the one-time password as the password.
Halo has no custom-header field, so Basic Authentication is how a delivery proves it came from your instance. Clarion rejects any delivery without it. Never put the password in the payload URL.
  1. Under Events, add the event profile Clarion should see — for example New Ticket Logged. Each event’s own conditions decide which tickets are sent, so start narrow: a webhook that fires on every ticket sends your whole service-desk volume to Clarion.
  2. Leave the payload on Full object with linked objects and save.
Clarion only needs the ticket id from the delivery — it reads the summary, details, status, priority, client, and assigned agent back through the credentials from Step 2, so what an agent sees is the current ticket rather than a snapshot of whatever the payload carried. The smaller payload shapes work too, and the whole delivery is kept on the signal either way so you can see exactly what Halo sent. Name the event so filters can match it. Halo’s built-in payload shapes do not say which event profile fired, so every delivery arrives as the generic event type halo_ticket. To route on the event, switch the payload to Custom payload and add an event field naming the profile:
Clarion lowercases it and replaces the spaces, so a filter matches the event type new_ticket_logged. Keep the ticket id in the body alongside it — that is the one field the read-back needs. A link, url, or permalink field in the payload is carried onto the issue too, so an agent can open the ticket in one click. Clarion only honours it when it points at your own Halo instance — the body is public once the webhook URL leaks, and an off-host URL on an issue is a phishing risk. A …/ticket?id=N link also tells Clarion which ticket to read back, which is worth knowing: Halo prepends its own id for the delivery row to every payload, so a custom payload whose only other identifier is that bare id would otherwise be matched to the wrong ticket. A link, an object_id, or a ticket_id all resolve it unambiguously — include one of them.
The value is literal text, not a variable, so it describes whichever profile this webhook fires on. Create one webhook per event profile — one for New Ticket Logged sending "event": "new ticket logged", another for Ticket Reassigned sending "event": "ticket reassigned" — rather than one webhook subscribed to several.
Choose what opens an issue. Each delivery becomes a signal. A new monitor starts with an All Halo tickets filter, so every delivery opens a Clarion issue out of the box. Narrow it by editing that filter or adding your own — conditions can match ticket.priority, ticket.client, ticket.type, ticket.category, or any field on the delivered payload, and a filter’s event type matches the event you named above.
Halo priorities are configured per instance. When a ticket’s priority is one of Halo’s defaults (Critical, High, Medium, Low), Clarion maps it onto the issue’s severity; otherwise the monitor’s Default severity applies. To route a renamed priority, add a filter that matches ticket.priority directly.

​
What agents can do

Once connected, agents on this workspace gain access to the /halo action, which exposes these tools:
create_ticket, update_ticket, close_ticket, add_comment, and execute_action write to Halo, so they require human approval before they run — you stay in control of when a ticket is actually changed. search_tickets, get_ticket, list_actions, list_outcomes, list_statuses, list_clients, and list_agents are read-only. Approval policies are managed in Settings → Tools.Work in Halo happens through actions: applying an outcome is what runs a workflow, moves the status, holds the SLA, and sends notifications. execute_action exposes that directly, and list_outcomes tells the agent which outcomes your instance configures, which of them close a ticket, and which send an email.Outcomes that email a recipient they don’t name need care: Halo asks for an “Email To” when the action is posted, and choosing who gets mailed is a notification decision rather than a ticket edit. Run the action with sendEmail false to apply the outcome without sending its email — nothing is mailed, so no recipient has to be chosen — or set that outcome’s Email To in Halo. close_ticket suppresses the email automatically when its closing outcome needs a recipient, and says so in the result.close_ticket is the same mechanism with the outcome chosen for you: it applies your instance’s own closing action, so the closure workflow fires rather than the status being edited behind Halo’s back. The outcome decides the resulting status — which may be a pending-closure one — and the result reports the ticket as Halo left it. Pass an explicit status ID to skip the workflow and set one specific status instead; that is also the fallback on an instance where no outcome closes. A closing note is recorded either way — the closing action carries it, and the direct-status path records it as a private note.add_comment is retry-safe: if the ticket’s most recent note is already identical, it returns that note instead of posting a duplicate. Halo requires every action to carry an outcome, so the note is posted with your instance’s own private- or public-note outcome depending on the visibility you asked for.

​
Disconnect

To remove the integration:
  1. In Clarion, open Integrations → Halo (HaloPSA).
  2. Click Disconnect.
This deletes the stored credentials. Agents on this workspace will no longer see the /halo action, and any saved skills that reference it will surface the integration as missing until you reconnect.

​
Troubleshooting

​
”Halo rejected the client credentials”

The Client ID or Secret is wrong, the application is not set to the Client Credentials method, or it lacks ticket permissions. Re-check the application in Configuration → Integrations → Halo API.

​
”Halo returned 404”

The Halo URL is likely wrong. Use your web-app base URL (e.g. https://acme.halopsa.com), not the /api or /auth path. For hosted solutions, confirm your Tenant and Authorisation server URL.

​
No issues appearing from the webhook

Confirm the Halo monitor exists and is attached to an agent, that the webhook’s events actually match the tickets you expect, and that the monitor’s filters have not narrowed everything away.

​
Deliveries rejected

Check the webhook’s Authentication in Halo. It must be Basic Authentication with the one-time password as the password — not None, and not the password pasted into the payload URL. If you have lost the password, rotate it on the monitor and set the new one in Halo.

​
Tickets arrive without a summary or detail

Clarion could not read the ticket back through the API, so it ingested the delivered payload instead — the issue’s description shows exactly what arrived. Check that the integration is still connected and that the webhook’s payload carries the ticket id.