Freshservice n8n integrationAutomate Freshservice with n8n.

Adds a technician to the helpdesk and sets, in the same call, what that person is allowed to touch.

• Email: the agent login address, in the name@email.com shape.
• First Name: the given name carried across the helpdesk.
• Roles: one entry per role, each pairing a Role Name or ID with a Scope (entire_helpdesk, member_groups, specified_groups or assigned_items); Group Names or IDs only matters when the scope is Specified Groups.
• Additional Fields: 13 extras, among them Job Title, Department Names or IDs and Language.

Removes an agent record from Freshservice. This is the closing move of an offboarding flow, once the tickets that person held have been handed over.

• Agent ID: the identifier of the agent to delete. Typed in for a one off cleanup, or read from the item coming out of the previous node with an expression such as {{ $json.field }}.

Reads one agent record back, so the rest of the workflow can branch on what Freshservice actually holds about that person rather than on a guess.

• Agent ID: the identifier of the agent to retrieve, either fixed in the node or pulled from an earlier step with {{ $json.field }}.

Returns the agent roster as a list of items, one per agent, ready to be counted, filtered or written somewhere else.

• Return All: on, n8n walks the API pages and brings back every agent; off, Limit caps how many come back.
• Filters: 9 narrowing fields, including Department Name or ID, Job Title, Email, Language and Location Name or ID.

Changes fields on an agent already in the helpdesk. Only what you put in Update Fields is touched, the rest of the record stays as it is.

• Agent ID: the identifier of the agent to update.
• Update Fields: 15 fields to choose from, such as Job Title, Department Names or IDs, Location Name or ID, Group Names or IDs and Observer of Group Names/IDs.

Opens a new group of agents, the unit tickets get routed to rather than to a single person.

• Name: the group label agents will see when they assign a ticket.
• Additional Fields: 5 options, including Description, Member Names or IDs, Observer Names or IDs, Escalate to Agent Name or ID for the escalation email recipient, and Unassigned For, the delay before that email goes out (30m, 1h, 8h, 1d and so on).

Takes a group out of Freshservice. Useful once a squad has been merged into another one and the old queue is no longer a valid routing target.

• Agent Group ID: the identifier of the agent group to delete, hardcoded or taken from the previous node with {{ $json.field }}.

Fetches a single group and its settings, which is how a workflow finds out who sits in it and where escalation points before acting.

• Agent Group ID: the identifier of the agent group to retrieve.

Lists the groups defined in the helpdesk, one item per group, which is the fastest way to audit how work is currently split.

• Return All: switched on, every group comes back page after page; switched off, Limit sets the ceiling.

Edits an existing group without recreating it, so its identifier and the tickets pointing at it stay valid.

• Agent Group ID: the identifier of the agent group to update.
• Update Fields: 6 fields, among them Name, Description, Member Names or IDs, Escalate to Agent Name or ID and Unassigned For.

Reads one role definition. Roles are what decide the permissions an agent carries, so this is the lookup step before anything is granted.

• Agent Role ID: the identifier of the agent role to retrieve.

Brings back the roles configured in the helpdesk as a list, which is the raw material for any permission review.

• Return All: on, the whole set of roles is collected across API pages; off, Limit decides how many items arrive.

Publishes an announcement in the helpdesk, the notice users see instead of opening five identical tickets about the same outage.

• Title: the headline of the notice.
• Body: the text itself, HTML supported.
• Visibility: agents_only, grouped_visibility or everyone.
• Visible From: the timestamp at which the announcement becomes active.
• Additional Fields: 4 extras, including Visible Until, Department Names or IDs and Additional Emails.

Drops an announcement from Freshservice. The natural use is housekeeping, once a notice has stopped being true.

• Announcement ID: the identifier of the announcement to delete, often carried over from a node earlier in the run with {{ $json.field }}.

Retrieves one announcement, headline and body included, so a workflow can reuse its wording somewhere else.

• Announcement ID: the identifier of the announcement to retrieve.

Returns the announcements held in the helpdesk as a list of items, one per notice.

• Return All: enabled, every announcement is collected page by page; disabled, Limit caps the batch.

Rewrites a notice that is already live, which beats deleting it and publishing a second one that users then have to compare.

• Announcement ID: the identifier of the announcement to update.
• Update Fields: 5 fields, namely Title, Body, Visibility, Department Names or IDs and Additional Emails.

Declares a new category in the asset taxonomy, the shape under which laptops, printers or licences get filed.

• Name: the label of the asset type.
• Additional Fields: 2 options, Description and Parent Asset Type Name or ID, which hangs the new type under an existing one and keeps the tree readable.

Removes a category from the asset taxonomy. Typically the tail end of a tidy up, when a type was created by mistake or a technology has left the estate.

• Asset Type ID: the identifier of the asset type to delete.

Reads one asset type back, which is how a workflow checks a category exists and what it hangs under before using it.

• Asset Type ID: the identifier of the asset type to retrieve, set in the node or passed along with {{ $json.field }}.

Lists the asset types configured in Freshservice, one item per category, which gives you the taxonomy as data instead of as a screen.

• Return All: on, the full taxonomy comes back across API pages; off, Limit holds the response to a fixed size.

Adjusts a category already in use, keeping the assets filed under it attached to the same identifier.

• Asset Type ID: the identifier of the asset type to update.
• Update Fields: 2 fields, Name and Description.

Planned IT work lives in Freshservice as a change record. This operation opens one with its window already set.

• Requester Name or ID: who asks for the change. Pick it from the list, or pass an ID through an expression such as {{ $json.field }}.
• Subject: the line agents scan in the change queue.
• Planned Start Date and Planned End Date: the window, both required as dateTime.
• Additional Fields: optional, holding Change Type (1 Minor to 4 Emergency), Risk, Impact, Priority, Status, Description, Agent Name or ID, Group Name or ID and Department Name or ID.

Change records raised by a misfiring workflow clutter the calendar, and this operation clears one out of Freshservice.

• Change ID: the ID of the change to delete, as a string. It is the record identifier, not the subject line, so a workflow that only knows the title has to look the change up first.

One identifier in, one change record out. Use it when a workflow already knows which change it is dealing with and needs the current state of it.

• Change ID: the ID of the change to retrieve. Hardcode it for a fixed record, or read it from the previous node with an expression like {{ $json.field }}.

Reading changes in bulk is how reporting workflows start. This operation returns a list rather than a single record.

• Return All: switched on, n8n walks the API pages and brings back every change; switched off, Limit caps how many come through.
• Filters: Predefined Filters narrows the list to closed, my_open, release_requested, requester_id or unassigned; Sort Order takes asc or desc; Updated Since keeps only changes touched after a date.

Changes move along as approvals come in, and this operation writes that movement back to the record.

• Change ID: the change to update. Everything else is optional, so only the fields you fill get touched.
• Update Fields: Status steps through 1 Open, 2 Planning, 3 Approval, 4 Pending Release, 5 Pending Review and 6 Closed; alongside it sit Agent Name or ID, Group Name or ID, Requester Name or ID, Department Name or ID, Change Type, Impact, Priority, Risk, Description and Subject.

Departments are how Freshservice groups requesters, and creating them from a workflow keeps the service desk aligned with the HR system.

• Name: the only required field, the department label agents see when they assign a ticket.
• Additional Fields: Description for context, and Domains, a comma-separated list of email domains tied to the department.

Reorganisations leave empty departments behind. This operation removes one from Freshservice by its identifier.

• Department ID: the ID of the department to delete, a string. The department name is not accepted here, so resolve the ID first with Get many departments if all you have is a label.

A single department comes back from this operation, which is usually the lookup step in the middle of a longer flow.

• Department ID: the ID of the department to retrieve. When the ID travels with the item, point at it with an expression such as {{ $json.field }}.

Listing departments gives a workflow the mapping it needs between names and identifiers, which most other operations ask for.

• Return All: on, n8n pages through the API until the whole list is in; off, Limit sets the ceiling on how many departments come back.
• Filters: Name narrows the result to a department name instead of returning the full directory.

Renaming a team or attaching another mail domain to it goes through this operation, which edits a department already in Freshservice.

• Department ID: the department being edited, required.
• Update Fields: Name for the new label, Description for the internal note, and Domains for the comma-separated email domains associated with the department.

Offices, floors and warehouses are stored as locations in Freshservice. This operation adds one so assets and requesters have somewhere to sit.

• Name: the name of the location, required, and the label that shows up when an agent tags a ticket with a site.
• Additional Fields: Address, a fixed collection opened with the Add Address Fields button in the node.

Sites close, and the record should not linger in the site picker. This operation deletes one location.

• Location ID: the ID of the location to delete. It is the numeric record identifier rather than the site name, so pipe it in from a previous lookup.

Pulling a single location back is the step that turns an ID travelling through a workflow into something readable.

• Location ID: the ID of the location to retrieve, either typed in or read from the incoming item with an expression like {{ $json.field }}.

The full site list is what most reporting and validation workflows start from, and this operation returns it.

• Return All: enabled, n8n chains the API pages together and returns every location; disabled, Limit decides how many items come out of the node.

Moving a floor or correcting a street number does not need a new record. This operation edits the location already in place.

• Location ID: the location to update, required.
• Update Fields: Name to relabel the site, and Address, the fixed collection opened with Add Address Fields.

When the same incident keeps coming back, Freshservice tracks the root cause as a problem. This operation files one.

• Subject: the title of the problem, required.
• Requester Name or ID: the initiator of the problem, chosen from the list or supplied as an ID through an expression.
• Due By: optional dateTime for when the problem is due to be solved.
• Additional Fields: Agent Name or ID, Group Name or ID, Department Name or ID, Description, Impact, Priority and Status.

Duplicate problem records split the investigation across two threads. Deleting one keeps the history in a single place.

• Problem ID: the ID of the problem to delete. Only the identifier works, so a deduplication flow needs to fetch the list first and decide which record survives.

Fetching a problem by its identifier returns the record as it stands, which is what a status check needs before it decides anything.

• Problem ID: the ID of the problem to retrieve, typed in directly or carried over from an earlier node through an expression such as {{ $json.field }}.

Batch reads of the problem queue drive the review meetings, and this operation hands the whole set to the workflow.

• Return All: turned on, every problem comes back page after page; turned off, Limit fixes the maximum number of problems returned.

Investigations move on, and this operation writes what has been learned back onto the problem record.

• Problem ID: the record to edit, required.
• Update Fields: Status takes 1 Open, 2 Change Requested or 3 Closed; the rest covers Subject, Description, Due By, Impact, Priority, Agent Name or ID, Group Name or ID, Department Name or ID and Requester Name or ID.

A new product entry lands in the Freshservice catalog, ready for the assets bought later to point at it.

• Asset Type Name or ID: the asset type the product belongs to, picked from the dropdown or passed as an ID through an expression such as {{ $json.field }}, which reads a value from the item entering the node.
• Name: the product label agents will search for, so keep the vendor wording.
• Mode of Procurement: Buy, Lease or Both, which matters when leased hardware is tracked apart from bought hardware.
• Status: In Production, In Pipeline or Retired.

Removing a product clears the model from the Freshservice catalog. The node takes the identifier and nothing else, so the deletion belongs at the end of a workflow that has already decided what goes.

• Product ID: the ID of the product to delete. Freshservice expects the identifier, not the product name, which is why a lookup usually runs first and feeds the value in with {{ $json.field }}.

One product record comes back from the catalog, with the fields Freshservice holds about that model. Reading before writing avoids blind updates.

• Product ID: the ID of the product to retrieve, often carried over from a previous step with an expression like {{ $json.field }}, which points at a value on the incoming item.

The full product catalog flows out of the node, one item per product, which makes it the starting point of any export or reconciliation.

• Return All: switched on, n8n follows the API pages until every product recorded in Freshservice has been returned.
• Limit: with Return All switched off, this caps how many products come out, which keeps a first test run short.

Existing product details change without touching the rest of the record. Only the fields filled in the Update Fields collection are sent, so an automation can move one attribute and leave the others alone.

• Product ID: the ID of the product to update.
• Status: In Production, In Pipeline or Retired, the field that marks a model as no longer orderable.
• Manufacturer: the vendor behind the model, worth fixing when catalog entries were imported with inconsistent names.

Planning a release in Freshservice starts here: the node opens the release record with its subject and its planned window.

• Subject: the title of the release, the line people read in the release list.
• Planned Start Date: the date and time work is meant to begin, in a dateTime value.
• Planned End Date: the date and time it is meant to be finished.
• Release Type: Minor, Standard, Major or Emergency, which is how the release desk sorts what is coming.

Cancelled release records disappear from Freshservice once the node runs. The operation is deliberate and narrow: it takes the identifier of one release and acts on it.

• Release ID: the ID of the release to delete, which a search or a form answer usually supplies as {{ $json.field }}.

Reading back a single release gives the workflow what Freshservice currently holds for it, subject and planned dates included.

• Release ID: the ID of the release to retrieve. It is an identifier, not the subject line, so a search step normally runs before this one.

Release records arrive as a list, one item each, which is what a reporting or a planning workflow needs to loop over.

• Return All: on, the node keeps requesting pages from the API until the whole set of releases has come back.
• Limit: off Return All, it sets the maximum number of releases returned, handy while the workflow is still being shaped.

Progress on a release gets written back into Freshservice. Whatever is left empty in the Update Fields collection stays as it was in the record.

• Release ID: the ID of the release to update.
• Status: Open, On Hold, In Progress, Incomplete or Completed.
• Group Name or ID: the agent group the release is assigned to, chosen from the list or given as an ID.

Freshservice gains a requester profile, meaning an end user who can raise tickets rather than work on them.

• First Name: the only field the node insists on, so a profile can be created from very little.
• Primary Email: the address the person will be recognised by when they write to the service desk.
• Department Names or IDs: the departments attached to the requester, as comma separated IDs.
• Job Title: useful when routing rules depend on the role.

When someone leaves the company, their requester profile can be removed from Freshservice by this operation rather than by hand.

• Requester ID: the ID of the requester to delete. A search on the person usually runs first, and its result is passed here with {{ $json.field }}.

Pulling one requester profile hands the workflow what Freshservice knows about that person, which is often the context a later step is missing.

• Requester ID: the ID of the requester to retrieve, not the email address, so a lookup or a stored identifier has to provide it.

Requester lists come out of the node one person per item, and the Filters collection narrows the set before it ever reaches the workflow.

• Return All: on, every matching requester is fetched page after page.
• Limit: off Return All, it caps the number of requesters returned.
• Department Name or ID: restricts the list to one department.
• Primary Email: finds the profile behind a known address.

Changing what Freshservice knows about a person happens field by field: the Update Fields collection carries only what the workflow decides to send.

• Requester ID: the ID of the requester to update.
• Location Name or ID: the site the person is attached to, picked from the list or given as an ID.
• Time Format: 12h or 24h, which changes how times read in that person portal.

Grouping requesters starts with creating the group itself, which service catalog rules and announcements can then target.

• Name: the group label, the one agents will see when they pick an audience, so it is worth naming it after the population rather than after the project.
• Description: a line explaining who belongs in it, which saves the next person a guess.

Obsolete requester groups go away with this operation, which keeps the audience picker readable for the agents who use it every day.

• Requester Group ID: the ID of the requester group to delete, usually read from an earlier listing step and passed along as {{ $json.field }}.

Details of a single requester group come back, which is how a workflow checks that the audience it is about to use is the one it thinks.

• Requester Group ID: the ID of the requester group to retrieve, a value a previous listing or a stored configuration provides.

Every requester group configured in Freshservice can be listed in one call, which is the easiest way to see how the population has been carved up.

• Return All: on, the node pages through the API and returns the complete set of groups.
• Limit: with Return All off, it fixes the maximum number of groups returned.

Renaming a requester group, or explaining it better, goes through this operation. The fields left empty keep their current value in Freshservice.

• Requester Group ID: the ID of the requester group to update.
• Name: the new name of the requester group.
• Description: the description of the requester group, the place to record what the group is for.

Adds an application to the Freshservice software inventory, so a newly approved tool joins the catalog instead of a spreadsheet.

• Application Type: required, one of desktop, mobile or saas, which is how the inventory separates installed software from subscriptions.
• Name: required, the label the IT team will search on later, often {{ $json.field }} when the value arrives from a request form.
• Status (Additional Fields): Needs Review while a security check is pending, Restricted once conditions apply.

Removes one application record from the Freshservice software inventory. Useful at the end of a decommissioning project, when a retired tool should no longer show up in the catalog.

• Software ID: required, the identifier of the software application to delete. It comes from a previous step rather than from the interface, typically as {{ $json.field }} after a Get many software applications call.

Reads one application from the inventory and passes its data to the rest of the workflow, where later nodes can reuse it.

• Software ID: required, the identifier of the software application to retrieve. Keep the identifier, not the application name, and reference it with an expression such as {{ $json.field }} when it travels from an earlier node.

Returns a batch of applications from the inventory in one call, which makes it the usual starting point for reporting and cleanup runs.

• Return All: switch it on and n8n walks the API pages until every application has been returned.
• Limit: with Return All off, this caps how many applications come back, which keeps a test run short while a workflow is still being built.

Edits an application already present in the inventory. Only the fields filled in under Update Fields are sent, so the rest of the record stays as it is.

• Software ID: required, the identifier of the software application to update.
• Status (Update Fields): move an app to Restricted once security sets conditions on it, or to Disabled when it is no longer allowed.
• Application Type, Name, Description, Notes (Update Fields): correct a label or record what the review concluded, without touching anything else.

Opens a ticket in Freshservice from data the workflow already holds, which is how an alert or a form answer becomes something the service desk can actually work on.

• Email: required, the email address of the ticket author, in the name@email.com shape.
• Subject and Description: the one-line summary and the body, where Description accepts HTML.
• Priority and Status: Urgent for an outage, Open for a fresh request that nobody has picked up yet.
• Group Name or ID (Additional Fields): pick the team from the list, or pass an identifier with an expression.

Deletes a single ticket in Freshservice. Worth keeping behind a condition in the workflow, since the service desk usually wants a trace of what came in.

• Ticket ID: required, the identifier of the ticket to delete, normally carried over from the step that found it, written as {{ $json.field }}.

Fetches one ticket and hands its content to the following nodes, so a workflow can decide what to do with the real state of the request instead of a stale copy.

• Ticket ID: required, the identifier of the ticket to retrieve. It is an identifier, not a subject line, and usually arrives from a previous node as {{ $json.field }}.

Pulls a list of tickets in one step, with a Filters collection to narrow the batch before it reaches the rest of the workflow.

• Return All: on, n8n pages through the API until every matching ticket is returned; off, Limit sets the ceiling.
• Status, Priority, Impact (Filters): keep only Open and Pending tickets, or only the High and Urgent ones.
• Agent Name or ID, Group Name or ID, Created On, Due By (Filters): scope the batch to one team, one assignee or one date.

Applies changes to a ticket that already exists. Fields left empty under Update Fields are not sent, so a workflow can touch one attribute without overwriting the rest.

• Ticket ID: required, the identifier of the ticket to update.
• Status and Priority (Update Fields): move a ticket to Resolved once an automated fix lands, or raise it to High when it ages.
• Group Name or ID and Department Name or ID (Update Fields): reroute the ticket to the team that owns the topic.