Before you begin
- An Enterprise plan or above. The Integrations hub is locked below Enterprise
- The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
- A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
- A ConnectWise Manage API Member with a public and private key pair, created by a ConnectWise administrator
- A ConnectWise Developer Client ID (a GUID) from developer.connectwise.com
- A ConnectWise Manage site that is reachable from the internet (cloud-hosted sites are)
What you can do
- Create ConnectWise tickets automatically from Atlas alerts and failed deployments, with a rule per kind of problem that picks the board and priority.
- Avoid ticket storms: one open ticket per affected resource, a per-rule cool-down, and quiet hours during maintenance windows.
- Close tickets automatically when the Atlas alert is resolved, and add a note when the issue recovers.
- Create a ticket by hand from a session host's page or a failed deployment, with the error already filled in.
- Map Atlas tenants to ConnectWise companies so every ticket and configuration lands on the right company.
- Keep host pools, session hosts, golden images, virtual networks, resource groups and AVD workspaces as ConnectWise configurations, updated every hour.
- Watch ticket volume, API performance and sync health on the integration page, on dashboard widgets, and in Atlas Advisor (Is ConnectWise syncing?).
Step 1: Create API credentials in ConnectWise Manage
- In ConnectWise Manage, go to System → Members → API Members and add an API member for Atlas.
- Give it a security role that can read and update service tickets and ticket notes, read service boards, priorities and statuses, read companies and contacts, read configuration types, and add and update configurations. Read system information is used for the connection test.
- Open the member's API Keys tab, add a key, and copy the Public Key and Private Key. The private key is shown only once.
- Get a Client ID for your integration from the ConnectWise Developer portal (developer.connectwise.com). It is a GUID.
- Note your Site URL (the address you sign in at, such as https://na.myconnectwise.net) and your Company ID (the company you type when you sign in).
Step 2: Connect in Atlas
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the ConnectWise Manage card.
- Enter the Site URL (the host only, without /v4_6_release or any path), Company ID, Public Key, Private Key and Client ID, and save.
- Click Manage to open the ConnectWise Manage page, go to Settings, and click Test Connection. A successful test shows Connected to your company with the round-trip time, and the status badge changes from Degraded to Connected.
Saving does not test the credentials; Test Connection does. Until a test succeeds, the integration shows Degraded. Keys are stored encrypted and shown masked; to change them, type new values on the Settings view and click Save Credentials.
Step 3: Map companies and boards
- Companies: click Add Mapping, enter the Atlas tenant ID, search ConnectWise companies by name and pick one. Tickets and configurations for that tenant use this company. If you have only one mapping, everything uses it; with none, ConnectWise applies its own default company.
- Boards: click Add Board, pick a service board, and mark one as the default. These are the boards offered when someone creates a ticket by hand.
Step 4: Create automation rules
On the Automation view, click Add Rule. Give the rule a name, pick a Trigger Condition, the Service Board and Priority its tickets use, and a Debounce in minutes (5 by default). Optionally set a maintenance window (start, end and an IANA time zone such as America/New_York) during which the rule opens no new tickets.
- Trigger conditions: Session Host Unhealthy, Session Host Unavailable, Deployment Failed, Golden Image Build Failed, High CPU Alert, Login Failure Spike and Unexpected Drain Mode. A condition matches Atlas alerts whose name or type contains its keywords, and Deployment Failed also fires when a host pool deployment or an Add VMs run fails.
- One ticket per resource: while a rule's ticket for a session host or host pool is open, the same problem does not open another one. If a second rule matches the same resource, it adds a note to the existing ticket.
- Debounce: after a rule opens a ticket, it opens no other ticket for the number of minutes you set.
- Tickets are titled [Atlas AVD] followed by the rule name and the resource, and the description carries the alert, resource, severity, time and message.
How tickets are closed
- When someone resolves an alert in Atlas, its open ConnectWise tickets are closed straight away.
- When an alert recovers on its own, Atlas adds an Issue resolved note to the ticket.
- Every 15 minutes Atlas also closes tickets whose Atlas alert has been resolved or dismissed, so dismissing an alert closes its ticket at the next check, and notices tickets your team closed in ConnectWise (status Closed, Resolved or Cancelled) so the same problem can open a fresh ticket next time.
Create a ticket by hand
When the integration is enabled, a Create Ticket button appears on each session host's page and on failed deployment rows on a host pool's page. It opens Create ConnectWise Ticket with a summary (up to 200 characters) and description (up to 2,000) already filled in, including the deployment error, plus the Service Board and Priority. The company comes from your company mapping. Users with permission to manage VMs can create tickets, not only administrators.
Config Sync
On Config Sync, click Add and map an Atlas resource type (Host Pools, Session Hosts, Golden Images, Virtual Networks, Resource Groups or AVD Workspaces) to a ConnectWise configuration type, entered by its numeric ID. Atlas then creates or updates one ConnectWise configuration per resource, marked Active, on the mapped company, every hour; Sync All runs it now. Each configuration carries an atlas: device identifier, so later runs update it rather than adding another.
Find a configuration type's ID in ConnectWise under Setup Tables → Configuration Types: open the type and read the ID from the address bar.
Monitoring the integration
- Overview: open Atlas-created tickets, active rules, failed syncs, API calls over the last 30 days, average latency, error rate, and a chart of tickets created per day.
- Health Status: the same health signals, updated live.
- Activity: the 50 most recent calls Atlas made to ConnectWise, with method, status, latency and result.
- Webhooks: the 50 most recent events ConnectWise sent to Atlas, with whether each signature was valid.
- Dashboard widgets: CW Open Tickets, CW Ticket Trend, CW Sync Status, CW Automation Health and CW Company Coverage.
- Atlas Advisor answers questions such as Show ConnectWise PSA health, with or without an AI provider.
Ticket updates from ConnectWise (webhooks)
Settings → Webhook Configuration shows your tenant's inbound webhook address, with a Copy button. When ConnectWise sends ticket events there, Atlas resolves the linked Atlas alert as soon as the ticket is closed or resolved, tracks status changes, and records public ticket notes. Each request must be signed with your tenant's webhook secret. The secret is not shown in the Atlas console yet, so contact Atlas support if you want to set up webhooks. Without them, tickets still close from Atlas, and Atlas still notices tickets closed in ConnectWise within 15 minutes; only the Atlas alert stays open until someone resolves it in Atlas.
What the integration does not do
- It connects ConnectWise Manage only. There is no Autotask, HaloPSA or ServiceNow connector.
- It does not sync time entries, agreements, invoices, projects, opportunities, members or contacts, and does not read companies beyond the search on the Companies view.
- Config Sync only adds and updates configurations in ConnectWise; it never deletes one. Every mapping syncs hourly, whatever its Sync Interval says.
- The Priorities view's severity-to-priority mappings are saved but not used yet: automated tickets take the priority set on their rule.
- The Last Sync shown in the page header and on Overview reads Never even when Config Sync runs; the Config Sync view shows each mapping's real last sync.
- Ticket notes pulled from ConnectWise are stored, but not shown in the Atlas console yet.
- It connects one ConnectWise Manage site per Atlas tenant, and cannot reach a site on a private network.
- Activity, sync and webhook history is kept for 90 days.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to ConnectWise Manage are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from ConnectWise Manage stay empty. The operator who runs your Atlas deployment can approve ConnectWise Manage as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.
Disabling and disconnecting
- Disable: on Settings, switch Integration enabled off and click Save Credentials. Your keys and settings stay, but automation, Config Sync, webhooks and the Create Ticket button stop until you switch it back on.
- Disconnect: click Disconnect on the card and confirm. Atlas deletes the stored keys and webhook secret and pauses any Atlas Vault asset sync from ConnectWise. Company, board and configuration mappings and your automation rules are kept, so reconnecting picks them back up. Nothing in ConnectWise is deleted. Reconnecting creates a new webhook secret.
Troubleshooting
- Status shows Degraded: run Test Connection on the Settings view. It changes to Connected once a test succeeds.
- Connection test failed: check the Site URL is the host only, the Company ID matches your sign-in company, the keys belong to an active API member, and the Client ID is a valid GUID from the Developer portal.
- Invalid siteUrl: the address is not a valid URL, or it points at a private or internal address.
- No tickets are created: check the rule is enabled, the integration is enabled, the alert's name matches the trigger's keywords, a maintenance window is not active, and the rule is not inside its debounce. A resource that already has an open ticket from the rule gets no second ticket.
- Tickets land on the wrong company: add or fix the company mapping for that tenant on the Companies view.
- A ConnectWise configuration sync is already running: wait for it to finish and try again.
- Failed to create ticket: check the API member's role can add tickets on that board. If you see the ticket was rolled back, nothing was left half-created; try again.
- Webhook events show Invalid in the Signature column: the request was not signed with your tenant's current secret. Reconnecting creates a new secret, so update the sender after a reconnect.