HaloPSA n8n integrationAutomate HaloPSA with n8n.

This operation opens a new client record in HaloPSA and returns what the API sends back about it.

• Name: the client name, and the only required field. Type it in, or read it from an earlier node with an expression, the n8n syntax that pulls a value out of the incoming item.
• VIP: a boolean in Additional Fields that records whether the client is VIP or not.
• Website: optional, and worth filling when the same company shows up twice in a list.

Removing a client record takes a single field. Hand the node the identifier and the record goes.

• Client ID: the identifier of the record to remove. It is an ID, not a company name, so read it from a previous step with something like {{ $json.field }} instead of typing it by hand.

Point the node at one client and it brings that record back, ready for whatever comes next in the workflow.

• Client ID: the record to read.
• Simplify: switched on, n8n returns a simplified version of the response instead of the raw data, which makes the next nodes much quicker to map.

Instead of a single record, this one lists clients, page after page when you ask for it.

• Return All: on, n8n walks through every page of clients the API hands back; off, Limit sets the maximum number returned.
• Active Status: Active Only keeps active customers, Inactive Only keeps the inactive ones, All returns both.

Existing record, new values. The node sends the fields you fill in the Update Fields collection.

• Client ID: which record the change lands on.
• VIP: the same boolean as on creation, so an account can be promoted later.
• Notes: free text, useful for recording why the change happened.

A site always hangs off a client, so this call needs both pieces before it can run.

• Name: the site name.
• Client ID: the client the site belongs to.
• Select Client by ID: a boolean that states whether the client can be selected by ID.
• Phone Number and Main Contact: both optional, in Additional Fields, and both worth filling for a location an engineer may have to call.

Drop a location out of a client structure in one call. The operation asks for nothing beyond the identifier, which makes it easy to chain after a check step.

• Site ID: the site to remove.

Reading a single site gives you its record on its own, without pulling the whole client structure.

• Site ID: the site to read.
• Simplify: returns a simplified version of the response instead of the raw data.

Sites pile up quickly on a growing account, and this operation is how you get the list back.

• Text To Filter By: filters sites by your search string, which is the fastest way to find a location when you only know part of its name.
• Return All and Limit: fetch every page, or stop at a set number of sites.

Changing a site record works through the Update Fields collection, and the identifier sits outside it.

• Site ID: the node does not mark it as required, so fill it in yourself to say which site the change targets.
• Client ID: moves the site under another client.
• Main Contact: the name recorded for the location.

Tickets are where this node earns its keep. Three fields are required, and the ticket exists.

• Ticket Type Name or ID: choose it from the list, or specify an ID using an expression when the type depends on the incoming data.
• Summary: the one line an agent reads in the queue.
• Details: the body of the request.
• Target Date: optional, in Additional Fields, and the field that decides where the ticket sits in a date sorted view.

Duplicate tickets happen, usually when a workflow retries a step that had already succeeded. This operation clears them.

• Ticket ID: the ticket to remove, and the only field the operation takes.

Pull one ticket back by its identifier when a later step needs the current state rather than the state you saw earlier.

• Ticket ID: the ticket to read.
• Simplify: a simplified version of the response instead of the raw data, which keeps a notification template short.

Lists of tickets are the raw material of every report, and this is the operation that produces them.

• Return All: on, n8n chains through the pages until the queue is fully read; off, Limit caps how many tickets come back.
• Text To Filter By: filters tickets by your search string.

Work moves, and so does the ticket. Update Fields carries the changes, the identifier stays outside the collection.

• Ticket ID: not marked required by the node, but it is what tells HaloPSA which ticket to change.
• Assigned Agent Name or ID: choose from the list, or specify an ID using an expression.
• Target Date: pushed back when the customer asks for more time.

Users sit under a site, which is why this operation asks for both a name and a site.

• Name: the user name.
• Site Name or ID: choose from the list, or specify an ID using an expression.
• Email and Surname: optional, in Additional Fields, and the pair that makes a user findable later.
• Password: if you set one, it needs at least 8 characters with a letter, a number or symbol, one upper case and one lower case character.

Offboarding ends here. One identifier, one call, and the user record is gone from HaloPSA.

• User ID: the user to remove.

One user, one call. The node returns the record so you can check it before acting on it.

• User ID: the user to read.
• Simplify: a simplified version of the response rather than the raw data.

Listing users is how you answer the question every account review asks: who is allowed to raise tickets here?

• Simplify: keeps the response light when you only need names to compare.
• Active Status: Active Only, Inactive Only, or All.
• Return All and Limit: read every page, or stop early while you are testing.

Moving a user or correcting their details goes through Update Fields, the widest collection of the four resources.

• User ID: the node leaves it optional, so set it to target the right person.
• Site Name or ID: choose from the list, or specify an ID using an expression, and the user follows their new location.
• User Is Inactive: a boolean, gentler than deletion when someone is only away.