Before you start

• ISV has a Bitlync key and a tenant for this MSP
• MSP can sign in to their Halo or ConnectWise as admin (or someone who can make an API app / API member)
• MSP knows they will paste keys into Bitlync Connect (hosted). Those keys stay in Bitlync Connect
• Decide which PSA is first for this MSP (Halo or ConnectWise). One connection at a time

1. Open Connect

• From the ISV product (or Bitlync link), MSP opens the hosted Connect link for that vendor
• MSP accepts MSP Connect Terms before keys save
• Follow the numbered steps beside the fields (Halo: client ID, secret, auth + resource URLs; ConnectWise: company id, public/private keys, client id, base URL)

2. Keys and permissions

• Paste credentials
• Bitlync tests the connection in the flow
• If something is missing, fix the named permission in the PSA, then re-test
• Prefer a dry_run / preview where the product offers it before real writes

3. Map companies (Match / company import from PSA / Skip)

PSA companies are the book. Match links an ISV customer. Company import creates that customer in the ISV.

• Review rows that need a choice (Needs match = not chosen yet — not a fourth outcome)
• Ambiguous names: Match by hand
• Exact-name hits may auto-Match — that is Match, not import

4. Bulk company import (unmatched)

When many PSA companies should become ISV customers (~dozens to ~150):

• Let exact-name Match run first
• Preview with dry_run: who will import, who is skipped (already Matched, Skip, ambiguous, not selected)
• Explicit MSP action only: Import all unmatched and/or multi-select then import
• Import is an explicit MSP action. Ambiguous rows stay unmatched
• Run for real: watch per-row progress and errors. A failed row stays unmatched for retry; successes stay

5. Contacts (list / match only)

• After companies are mapped, read contacts under those companies
• Match on company + email (and vendor id when present)
• List and match contacts. Match on company and email, and on vendor id when it is present

6. Boards / statuses / priorities (ticket writes)

• Confirm Bitlync can list the PSA’s boards (or Halo teams), statuses, and priorities
• Use those when opening or updating tickets so writes land on a board/status the MSP recognizes
• Ticket create / update / note / close / time: preview with dry_run, then commit

7. Smoke check before calling it live

• Companies: Match and/or company import from PSA worked for the rows you care about
• Contacts: list/match under a mapped company
• Ticket: dry_run then one real create (or update) on a lab/low-risk company
• Billing: the MSP matches each service to an existing line on an existing agreement. You send an absolute quantity (0 stops billing). Bitlync never creates agreements or lines

8. Alerts

When alerts are on, Connect adds an alerts setup step. Back returns to the previous step. Continue saves and moves on. Choose where alerts go in your stack. Type is required. Subtype (ConnectWise), Item, and the Halo subcategory are optional and default to None. The message "ConnectWise requires Subtype on {board}." appears only when your stack mandates Subtype.

• If the page cannot save, it says "Reload the page and try again."
• If saves come too fast, it says "Too many saves. Wait a minute and try again."
• Done links to "Go to Activity"

9. Activity

Activity shows Needs your attention, a change log in your local time, Deliveries, and Send test ticket. Send test ticket is sandbox-only, 30 per minute. The public demo key cannot open the console Activity page (401), so this list was not checked against that screen.

Coverage for Halo and ConnectWise: Coverage. Sandbox curl: Quickstart. Alert catalog and routing: Alerts.