The PSA API tool appears in your agent automatically once you connect a PSA — there’s no separate toggle in the tool list. You control what it can do on the workflow’s Integrations tab.
What It Does
- Read and update tickets — status, priority, type, board/queue, assignee, custom fields
- Add internal notes, detail descriptions, and resolution notes
- Add client-facing notes (which your PSA may deliver as an email to the contact)
- Log time entries, set billable options and work types
- Merge and bundle duplicate or related tickets
- Look up and manage companies, sites, contacts, and configuration items
- Search the product catalog and add line items to tickets
- Manage schedule entries, appointments, and service calls
- Query agreements, SLAs, projects, opportunities, knowledge base articles, and other PSA records
- Reach any endpoint your PSA’s API exposes, gated by the permission groups you enable
Permission Groups
Each PSA integration is split into permission groups — for example Tickets, Ticket Notes, Time Entries, Contacts, Companies, Configurations, Products, Schedule Entries, Agreements, SLAs, Projects, Knowledge Base, Audit Trail, and more (the exact set varies by PSA). Every group has an access level:
A few groups have extra switches — for example, Tickets lets you enable merge and bundle separately, and lets you whitelist exactly which ticket fields the agent may change. Delete is off by default everywhere and must be turned on explicitly per group.
Autotask: pinning a Note Type on internal notes
On Autotask, the Ticket Notes (Internal) permission group at Read / Write has a Use Custom Note Type switch. Turn it on to pin a fixed Note Type and Note Publish on every internal note Neo writes, instead of letting the agent choose. This is useful when you have Autotask workflow rules that fire on notes — a dedicated note type lets those rules recognise Neo’s notes and treat them differently from a technician’s or a contact’s reply. The Note Publish options are scoped by audience: the Ticket Notes (Internal) group offers only internal values (Internal Project Team, Internal & Co-Managed), while the Ticket Notes (Client-Facing) group offers the customer-facing value (All Autotask Users). When set, the configured Note Type/Publish is applied to internal notes regardless of what the agent would otherwise pick.One deliberate exception: a note attributed to the technician who asked for it keeps its ordinary note type. The pinned type means “Neo wrote this”, so stamping it on a note Autotask is recording under a real person would make your own workflow rules treat that technician’s note as Neo’s. Notes Neo writes on its own — every automation, and anything it isn’t attributing to someone — still carry the pinned type.
HaloPSA: blocking spam senders with Email Rules
HaloPSA has an Email Rules permission group covering Halo’s inbound email rules (Configuration → Email → Email Rules). Its main use is stopping repeat spam at source: instead of an agent closing the same spam ticket every time that sender writes in, it adds an Ignore Email rule for the address and Halo stops raising tickets from it at all. That saves the credits those repeat closures would burn, and it works where Halo’s own “treat as spam” doesn’t — that option is UI-only, gated on agent role, and can’t be reached from Halo’s quick actions or workflows. Email Rules is separate from the Configuration group and read-only in every profile except IT Admin and Full Automation, so nothing changes until you grant it. Two things to know before you do:- It takes two switches, not one. Granting the permission group lets Neo read your rules; creating one also needs the
adminOAuth scope on your HaloPSA API application, which the standard Neo setup deliberately leaves off. Walkthrough: Letting Neo Manage Email Rules. - A rule that matches too broadly silently drops mail. Ignored email raises no ticket, so nothing surfaces for a technician to notice. Neo blocks one exact sender address per rule and won’t ignore a whole domain on its own; deleting the rule restores delivery. Turn on technician approval for this group if you’d rather see each block first.
Syncro: separating public comments from internal ones
Syncro has one comment endpoint for both kinds — a comment is customer-facing unless it carrieshidden=true, and Syncro emails the requester when a public one is added. Neo splits them into two permission groups anyway: a comment marked hidden needs Work Notes, and everything else needs Client-Facing Notes.
A comment sent with no visibility flag counts as public and needs Client-Facing Notes, because that is what Syncro does with it. To let an agent take notes without ever mailing a customer, grant Work Notes at Read / Write and leave Client-Facing Notes at Read Only.
Syncro’s permission groups are Tickets, Work Notes, Client-Facing Notes, Time Entries, Customers, Contacts, and Technicians. Tickets also covers the read-only status, priority, and ticket-type catalogs the agent reads before a ticket write, and reading a ticket’s comments — a plain ticket read returns them anyway, so the two notes groups control who can write a comment.
Everything Syncro exposes beyond those areas — invoicing, estimates, products, purchase orders, payments, appointments, assets, wiki, and its bundled RMM — is out of reach for agents. Two things are blocked even though they sit under an area agents can reach: ticket line items, because they feed invoices, and a customer’s stored payment methods, which agents can neither read nor change no matter how their permissions are set.
ServiceNow: what agents can read from attachments
The Attachments group lets an agent list what’s attached to a ticket — file name, type and size — read the contents of small text files (.csv, .txt, .log, .json, .xml and similar) up to 1 MB, and read images (screenshots, photos — .png, .jpeg, .gif, .webp) up to 8 MB. Images are never shown to the agent as raw pixels: Neo generates a written description of what the image shows — error dialogs, codes, visible UI state — and the agent works from that.
It stops there by design. Spreadsheets, .msg files, PDFs and other binary formats are listed but not opened, and files over the size limits are refused rather than truncated — an agent that guessed at a spreadsheet’s contents from its filename would be worse than one that says it can’t open it. The group is read-only in every access profile, including Full Automation: Neo cannot upload or delete attachments through it.
Screenshots embedded inline in ticket notes need no permission group — those are already described to the agent as part of the ticket. The Attachments group adds on-demand reads of files that aren’t referenced in the notes.
ServiceNow stores attachments per record, not per customer. Agents are directed to scope every attachment read to the ticket they’re working on, but the group itself has no company boundary — worth knowing before you grant it on an agent that serves multiple end clients.
ServiceNow: reading knowledge articles
The Knowledge Base group lets an agent search and read published articles, along with the knowledge bases and categories that organise them and any feedback left on an article. Grant it when your agents should resolve tickets using what your team has already written up — an agent handed a KB number in a ticket description can read that article instead of replying that it has no access. Articles built from templates (how-to, known-error, or your own custom templates) are covered too — their body lives in the template’s own table rather than the base article record, and Neo reads it from there. It is read-only in every access profile, including Full Automation. ServiceNow publishes articles through draft → review → published, and an article created over the API would sit as a draft nobody sees — a Business Rule quietly revertspublished when the connected account lacks publish rights. If you want an agent to help write articles, have it draft the content in its reply for a technician to publish.
If you run a separate knowledge base per end client, note that this group can read all of them — ServiceNow applies no company boundary to knowledge articles. Neo is directed to identify the knowledge base belonging to the ticket’s company and search within it, and never to quote another customer’s article. The connected ServiceNow account already has this same access, so this grants Neo no more reach than the technicians it works alongside — but it is worth knowing before enabling it.
ServiceNow: reading approvals
The Approvals group lets an agent read the approver rows on changes, requests and catalog items — who is on the approval, which group they belong to, and whether it is requested, approved, rejected or not required. It answers “who is this change waiting on”, and lets an agent build an approver list from your ServiceNow assignment groups. It is read-only, and unlike the other read-only groups this one isn’t a technical limitation: recording an approval is a decision that belongs to a person, and ServiceNow offers no way to undo it through the API. An agent can tell you a change is sitting with a particular approver; it won’t approve it for you. If you want that to change, it should be a deliberate conversation rather than an access-level toggle — approvals would come back with technician approval always required, regardless of how the rest of the agent is configured.Access Profiles
Quick-start profiles configure every permission group at once:Safety Controls
Self-Correcting Field Errors
PSAs often reject a bad request with an opaque error, which can send an agent into a loop of guessing field names. Neo catches these at the source: when a write uses a field the entity doesn’t have (a typo, or a field borrowed from a different entity), the error the agent receives is rewritten to name the invalid field and — for Autotask — list the entity’s actual valid field names. The agent corrects itself on the next attempt instead of retrying blindly. This runs automatically for every PSA write; there’s nothing to configure. Neo also checks the value of a dropdown field against your tenant’s own synced options before the write is sent — a status, priority, type, or queue the agent invented is rejected with your real options listed inline, so the agent picks a valid one rather than writing a wrong value or looping on a rejection. Which fields are covered varies by PSA, and a field is only checked once its options have synced; anything not covered still falls through to the PSA’s own validation.How to Configure
1
Connect your PSA
Set up the integration: ConnectWise, Autotask, HaloPSA, ServiceNow, or Syncro.
2
Choose an access profile
On the workflow’s Integrations tab, pick a quick-start profile or customize each permission group’s access level.
3
Pick allowed ticket fields
On the Tickets permission group, choose which fields the agent may update (status, priority, type, custom fields, and so on).
4
Set approval requirements
Decide which permission groups require technician approval for writes. Approval applies to the
whole group — on Tickets that includes closing a ticket, not just creating one. See
where approval can be required.