Connect your PSA

How tickets work

• One PSA connection per workspace. Setting it up needs the Admin or Owner role in ConfigCheckup.
• Credentials are tested with your PSA before they are saved, and secrets are stored encrypted.
• After each completed assessment, every failing control at or above the severity you choose gets a ticket, unless it already has an open one. Nothing is raised twice.
• When a later assessment shows the control passing, ConfigCheckup adds a note saying so and closes the ticket.
• When a control’s risk is accepted, its ticket is closed with a note saying so and when the acceptance is reviewed. Withdrawing the acceptance, or letting it run out, raises the ticket again if the control still fails.
• Each finding shows its ticket: the number, a link to it in your PSA and the status your PSA gives it. Create a ticket on a finding raises one by hand, whatever its severity.
• Priorities follow the finding’s severity. HaloPSA, Autotask and NinjaOne use their standard priorities; ConnectWise uses your board’s Priority 1 to Priority 4. Each connection takes four priority IDs, for critical, high, medium and low, if yours differ.
• Every ticket is written down in ConfigCheckup before your PSA is asked for it, so nothing is raised twice, even if something stops part-way. If your PSA does not answer, HaloPSA, ConnectWise and Autotask are searched for a ticket made since it was asked for, and it is raised again if there is none. In NinjaOne and Kaseya BMS the finding, alert or change says so, as do Needs you and Integrations, and waits for you to check and raise it again.
• Only tenants mapped to a company in your PSA get tickets, so you can start with one tenant.

Tickets closed in your PSA

After each assessment ConfigCheckup reads every open ticket back from your PSA. A ticket someone closed there while its control still fails is not closed quietly: the finding says so, with when. Under Settings → Integrations → Alerts, drift and admin work you choose what happens next: flag it on the finding only (the default), or raise it again after a day, 3 days, a week, 2 weeks or 30 days if the control still fails then. Raise it again on the finding does it straight away. A ticket opened again in your PSA is followed again.

Alerts, drift and admin work

• Security alerts: tick the severities (high, medium) that raise a ticket for each alert as it is found. The ticket is closed when the alert is dismissed in ConfigCheckup.
• Drift: tick the severities for which a critical control the drift check finds failing raises its ticket at once, rather than after the next assessment. It is the control’s own ticket, closed once it passes again.
• Admin changes: new starters, leavers, groups, licences and mailboxes that succeed can post a ticket saying what was done, what Microsoft showed when it was read back, and who approved it, closed as done. Choose Post a ticket and log time on it to log the minutes you set against it: in HaloPSA and NinjaOne on the ticket, in ConnectWise as a time entry (as the member you set, or the API member), and in Autotask as a time entry once you set the resource and role IDs for it. Kaseya BMS takes no time from ConfigCheckup.

Start in ConfigCheckup at Settings → Integrations, choose your PSA, then follow the steps for it below.

HaloPSA

Create the API application

1. 1In HaloPSA, go to Configuration → Integrations → HaloPSA API and select View Applications, then New.
2. 2Name it “ConfigCheckup” and set the authentication method to Client ID and Secret (Services).
3. 3Choose an agent for it to act as; tickets and notes are recorded against that agent.
4. 4On the permissions tab, allow it to read customers and to read and edit tickets. Save, then copy the client ID and secret.

Fill in the form

The company for each tenant is the customer's client ID in Halo, shown in the address bar when you open the customer.

The webhook: ticket status at once, and leaver tickets (beta)

Beta: built from HaloPSA's documentation and not yet tried against a live HaloPSA. Without the webhook, ConfigCheckup reads each open ticket back after every assessment. With it, a ticket closed or opened again in HaloPSA is followed straight away, and a new leaver ticket can draft an offboarding.

1. 1In ConfigCheckup, go to Settings → Integrations → Webhook and select Make the secret. Copy the webhook URL and the secret; the secret is shown only once.
2. 2In HaloPSA, go to Configuration → Integrations → Webhooks and add a webhook. Paste the URL, sent as a POST with a JSON payload.
3. 3Choose the events for a ticket being logged and a ticket being updated.
4. 4For authentication, add a header named X-Webhook-Secret holding the secret, or use basic authentication with any user name and the secret as the password. Save it.

ConfigCheckup takes only the ticket's ID from what HaloPSA sends, and reads the ticket again from HaloPSA itself before it does anything. A post without the secret is refused. Making a new secret stops the old one at once.

Leaver tickets

In the connection, set Leaver ticket type ID to the ticket type your team logs leavers with, and optionally a Leaver category. When a new ticket of that type is logged for a HaloPSA tenant mapped to one of your tenants, ConfigCheckup finds the leaver: in the custom field you name in Leaver email custom field ID, or else the first email address in the ticket's summary or details that is exactly someone's sign-in or email address at that tenant.

• With exactly one such person, an offboarding is drafted for them, made for that ticket, and an internal note on the ticket says where it waits. It is a draft: someone checks its dry run and sends it for approval, and nothing changes in Microsoft 365 until it is approved, as with any offboarding. When it runs, its result is noted on the ticket too, if admin changes post to your PSA.
• With nobody, or an address that is more than one person's, nothing is drafted and the note says why.

Each leaver ticket is acted on once, however often it is updated afterwards.

ConnectWise Manage

Create an API member and keys

1. 1In ConnectWise Manage, go to System → Members → API Members and add a member for ConfigCheckup. Give it a security role that can view companies and add and edit service tickets.
2. 2Open the member, go to the API Keys tab and create a key. Copy the public and private key; the private key is shown only once.
3. 3ConnectWise also requires a client ID for each integration. Create one at developer.connectwise.com under Client IDs.

Fill in the form

The company for each tenant is the company's record ID in ConnectWise (the number in the address when you open it).

Autotask

Create an API user

1. 1In Autotask, go to Admin → Account Settings & Users → Resources/Users and add an API user.
2. 2Give it the API User security level, or one that can view companies and create and edit tickets.
3. 3Generate the user name and secret, and under API Tracking Identifier choose a custom (internal integration) identifier. Copy all three.

Fill in the form

The company for each tenant is the company's ID in Autotask.

NinjaOne

Tickets use NinjaOne Ticketing, so it needs to be switched on for your account.

Create an API client app

1. 1In NinjaOne, go to Administration → Apps → API, open Client app IDs and select Add client app.
2. 2Choose the API Services (machine-to-machine) platform, name it “ConfigCheckup”, tick the Monitoring and Management scopes and the Client credentials grant type.
3. 3Save, then copy the client ID and the client secret; the secret is shown only once.

Fill in the form

The company for each tenant is the tenant's organisation ID in NinjaOne: open the organisation and take the number from the address. Tickets are raised as internal (not visible to the end user), tagged configcheckup.

Kaseya BMS (beta)

Beta: tested against API documentation, not a live account. Kaseya BMS tickets were built from Kaseya's published v2 REST API documentation. If a ticket does not appear or close as described, tell us what BMS answered.

Create an API user

1. 1In BMS, add a user of the API user type for ConfigCheckup. An API user cannot sign in to BMS and uses no licence.
2. 2Give it a security role that can create and update Service Desk tickets and notes.

Fill in the form

The company for each tenant is the tenant's account ID in BMS. Notes are added as internal notes.

Map tenants to companies

1. 1Choose the lowest severity to raise tickets for. High is a sensible start: critical and high findings only.
2. 2Save the connection. ConfigCheckup tests the credentials, tells you if anything is wrong, and lists your PSA’s companies.
3. 3Under Settings → Integrations → Companies, each tenant without a company is offered the companies that match it: the company’s website on one of the tenant’s domains, or the same name. Check them and save. The rest can be chosen from the full list, with a search, on each tenant’s settings under PSA company; a company not in the list yet can still be typed in. Refresh the list after adding companies in your PSA.
4. 4Run an assessment, or wait for the next scheduled one. Tickets appear once it completes.

Moving to another PSA asks first when tenants have companies in the current one. Each tenant’s company is then found by name in the new PSA, or cleared to be chosen again, and tickets already raised in the old PSA stay there: ConfigCheckup stops following them.

Tenant reports in your PSA

A tenant’s scheduled report can go to your PSA as well as, or instead of, by email. In the tenant’s Settings › Tenant report, choose how often (monthly, quarterly or after every assessment) and tick the box to post it to your PSA as a ticket. The tenant needs its company ID set first, under PSA company. The same choices are under Reports › Schedules for every tenant at once. Each report opens one ticket for the tenant’s company, with the score, what is failing by severity, and the report’s link, which works for 30 days. The ticket is low priority; ConfigCheckup does not close it.

If the PSA refuses, or the tenant has no company ID, the report’s row and the tenant’s settings say so with the PSA’s answer, the Owners and Admins are told, and the audit log records it. Nothing fails quietly, and nothing is posted twice.

RMM devices and alerts (beta)

Beta: tested against API documentation, not a live account. Connect Datto RMM, N-able N-central or NinjaOne under Settings → Integrations → RMM devices and alerts. ConfigCheckup only reads from the RMM; nothing is changed there. After each assessment it reads the devices and open alerts for each mapped tenant's site and shows, on the tenant's settings page:

• devices with an RMM agent that Intune and Entra do not know, which may be unmanaged by Microsoft 365;
• Windows, macOS and Linux devices in Intune or Entra with no RMM agent (phones and tablets are left out);
• the site's open alerts: type, device, priority and time. Alert diagnostics are not stored.

Devices are matched by serial number where both sides have one, otherwise by device name, ignoring case and domain.

Datto RMM

1. 1In Datto RMM, turn on API access under Setup → Global Settings → Access Control and note the API URL for your platform (for example https://merlot-api.centrastage.net).
2. 2Create a user for ConfigCheckup with read-only rights, and under Setup → Users generate its API key and API secret key.
3. 3Enter the API URL, API key and secret key. Each tenant's site is the site's UID, shown in its settings.

N-able N-central

1. 1Create a user for ConfigCheckup with read-only access to the customers you want matched.
2. 2Under Administration → User Management → Users, open the user, then API Access → Generate JSON Web Token.
3. 3Enter your server URL and the token. Each tenant's site is the customer's org unit ID in N-central.

We chose N-central over N-sight because N-central has a documented REST API with JSON answers and short-lived access tokens, while N-sight's API returns XML and takes its key in the address.

NinjaOne

1. 1In NinjaOne, go to Administration → Apps → API, open Client app IDs and add a client app with the API Services (machine-to-machine) platform, the Monitoring scope and the Client credentials grant. If NinjaOne is already your PSA here, its client app will do.
2. 2Enter your instance URL (for example https://eu.ninjarmm.com), the client ID and the client secret.
3. 3Each tenant's site is its organisation ID in NinjaOne: open the organisation and take the number from the address. NinjaOne gives each device's serial number, so its devices are matched with Intune's by serial first.

IT Glue and Hudu (beta)

Beta: tested against API documentation, not a live account. Connect IT Glue or Hudu under Settings → Integrations → Documentation, then choose each tenant's organisation (IT Glue) or company (Hudu), from the list or on the tenant's settings page under As-built page. Each mapped tenant gets one page there, called ConfigCheckup as-built, pushed every day and whenever you select Push now. It holds:

• the score and grade, and when the tenant was last assessed;
• the open critical and high findings, most serious first;
• each Conditional Access policy and whether it is on, report-only or off;
• when the GDAP relationship ends;
• the licences bought and assigned, and the devices by platform, with how many are managed and compliant.

Everything on it comes from the latest assessment. ConfigCheckup keeps the page's ID and updates the same page every time, so anything typed into it is replaced at the next push; a page deleted there is made again. Integrations names the tenants whose last push did not work, and each tenant's settings page shows when its page was last pushed and what the tool said. A saved key is only sent to the address it was entered for: change the region or the Hudu URL and enter the key again.

IT Glue

1. 1In IT Glue, go to Account → Settings → API Keys, open Custom API Keys and generate a key. It does not need password access.
2. 2Choose your region (United States, Europe or Australia) and enter the key.
3. 3The first push makes a flexible asset type called ConfigCheckup as-built (or uses one already named so), with a field for each part of the page; each tenant's page is one flexible asset of that type in its organisation. If the type is deleted, the next push makes it again.

Hudu

1. 1In Hudu, go to Admin → API Keys and make a new key. Leave it open to every company you will map. The as-built page does not need password access; give the key password access only if you want stored credentials shown on People (below).
2. 2Enter your Hudu URL (for example https://yourcompany.huducloud.com) and the key.
3. 3Each tenant's page is a knowledge base article filed under its company.

Stored credentials on People (Hudu)

With Hudu connected and a tenant mapped to its company, a person's panel on People shows Stored in Hudu to Technicians and above: each credential in that company whose username is the person's sign-in or email address (or the name before the @), with its name, the website it is for, when it was last changed, whether it has a one-time code, and Open in Hudu. A leaver's offboarding change lists the same credentials, to rotate. Nothing in Hudu is changed.

Details only: ConfigCheckup never stores, logs or shows a password or one-time code from Hudu. Hudu sends them with the list, so they are dropped the moment it is read, and only the details above are kept, in memory, for a few minutes. The key needs password access for this; without it the panel says so. Each look at someone's credentials is in the audit log.

Troubleshooting

• Saving fails: the message comes from your PSA. Check the URL is for the right region or zone, and that the API user is active.
• No tickets after an assessment: check the tenant has a PSA company set, the connection is enabled, and there are failing controls at or above your severity.
• Tickets are not closing: check the closed status ID belongs to the board or ticket type being used.
• A finding says its ticket was closed in your PSA: someone closed it there while the control still fails. Raise it again from the finding, or let the setting under Alerts, drift and admin work raise it again for you.
• No companies to choose from: the API user needs to read customers or companies. Refresh the list under Integrations once it can.

Prefer your own integration? The read API (on every plan), and webhooks (with Automate), give you the same findings to route however you like.