PSA Integrations Overview
Palisade connects to your Professional Services Automation (PSA) system to streamline email security management across your client base.
What PSA Integrations Do
- Import domains automatically -- Pull client domains directly from your PSA so you never have to add them manually.
- Synchronize billing information -- Keep domain counts and billing data in sync between Palisade and your PSA.
- Create tickets in the PSA -- Palisade's DMARC Agent opens an actionable ticket in your PSA when it finds an email authentication issue, for every domain in a group mapped to a PSA account.
PSA integrations require an MSP account. If you do not have an MSP account, you can upgrade at https://app.palisade.email/msp-program.
Before Tickets Can Reach Your PSA
Two things have to be true for a Palisade task to become a ticket. Both are easy to miss, and when either is missing Palisade raises the task in its own dashboard and opens nothing in your PSA.
Every domain needs a group, and every group needs a PSA account
Palisade organises domains into groups. A group is what carries the link to a customer record in your PSA -- a ConnectWise company, an Autotask client, a HaloPSA customer. Tickets are raised against the PSA account its group is mapped to, so:
- A domain in no group raises no PSA ticket.
- A domain in a group with no PSA account mapped raises no PSA ticket.
How a group gets its mapping depends on how the group came to exist:
| How the group was created | Mapping |
|---|---|
| Imported from your PSA, with the import button on the integration's settings page | Mapped automatically, at the moment it is created |
| Created by you, on the Groups page or through the API | Starts with no mapping. You have to map it yourself under Map PSA accounts |
If you organised your domains into groups before connecting your PSA, none of those groups are mapped. Open Map PSA accounts on the integration's settings page and map each one. Until you do, those domains raise nothing in your PSA -- there is no error at the point you create the group, because at that point nothing is wrong yet.
The integration's settings page shows a blue notice counting the tasks skipped for either reason, and the Logs tab lists them individually as Skipped, each naming the group and the domain. That notice is the fastest way to find a group you have missed.
A skipped task is not an integration error. Leaving a group unmapped is a legitimate choice -- internal domains, prospects, clients billed elsewhere -- so a skip is reported as information, is not counted by the error badge on the Logs tab, and never turns the integration's status to failed. A red notice means the sync itself is broken: bad credentials, a missing status mapping, a rejection from your PSA.
Mapping a group later does not backfill on its own -- but Palisade offers
When you map a group that already has open tasks, Palisade asks whether you want tickets created for the tasks that were raised while it was unmapped. Choose Sync Tickets and they are pushed; choose Skip and only tasks raised from that point on become tickets.
The same question is asked when you move a domain into a group that is mapped to a PSA account.
Tickets Wait Four Hours
A newly raised task does not reach your PSA immediately. Newly detected problems churn, so a task has to hold its state for four hours before Palisade pushes it. Two consequences:
- A task you can already see in the Palisade dashboard may not have a ticket yet.
- A task that opens and resolves inside that window never creates a ticket at all.
This is deliberate: it keeps self-resolving problems out of your queue. It is also the first thing to check before concluding that ticket creation is broken -- if you added a domain less than four hours ago, nothing has been pushed yet. The same four-hour window governs webhook task events.
Status updates on a ticket that already exists are not delayed.
Sync Runs One Way
Palisade pushes to your PSA; it does not read back from it. Palisade creates tickets and keeps their status, priority and type up to date, but closing a ticket in your PSA does not resolve the task in Palisade. Resolve the task in Palisade, or fix the underlying DNS record, and Palisade will move the PSA ticket to your mapped Done status on its next push.
Choosing Which Tickets Palisade Opens
Two settings decide what reaches your PSA: the kinds of work you want tickets for, and the clients you want them for.
By task type
Choose which tasks create tickets, on the integration's settings page, lists every kind of task the DMARC Agent raises: setting up a DMARC record, cleaning up an SPF record, confirming a sending source, and so on. Clear a type and Palisade stops opening tickets for it.
Every type is selected to begin with, so an integration you have already set up keeps behaving exactly as it does today until you change something here.
If your board feels noisy, SPF record cleanups are the first type worth a look. They are by a wide margin the most common task Palisade raises, and some teams would rather work them in Palisade and keep the PSA for everything else.
Two things to know before you clear a type:
- Tickets already open in your PSA stay open and keep receiving status updates from Palisade, so nothing a technician is already holding goes stale underneath them.
- Turning a type back on does not backfill. Tasks raised while it was off will not open tickets retroactively. Only tasks raised from that point on will.
By client
Ticket creation follows the PSA account mapping on a group. Remove the mapping and that whole set of domains stops raising tickets, whatever the task type settings say.
The email notification settings do not apply to any of this. They control Palisade's own email, and are not read when tickets are pushed to your PSA.
Supported PSAs
Palisade currently integrates with the following PSA platforms:
| PSA | Status |
|---|---|
| Autotask | Available |
| ConnectWise | Available |
| HaloPSA | Available |
Each integration supports domain import, ticket creation, and billing synchronization. Follow the setup guide for your specific PSA to get started.
Using something else
If your tooling is not one of the three above, webhooks are the general-purpose alternative: Palisade posts an event to a URL you control whenever a domain changes, and you decide what to do with it.