Skip to content

How connectors work

Every integration in Plugboard is a connector. The application never depends on Jamf, or Synergetic, or Zendesk. It depends on a capability, and a connector declares which capabilities it implements.

That is why a school running Intune and one running Jamf use the same repairs screen, and why swapping an MDM is a configuration change rather than a project.

Capability. A named operation the platform can ask for: device.lookupBySerial, sis.getRoster, email.send. Full list in capabilities.

Connector. A definition: a category, an authentication kind, a configuration form, a secret form, and the capabilities it implements.

Connector instance. A connector you have configured, with your URL and your credentials. Credentials are encrypted before they touch the database.

When a feature needs something done it asks for a capability. The platform finds an enabled instance implementing it and calls the handler. If there is no such instance, the feature says so plainly rather than failing obscurely.

Twenty-six connectors ship in the box.

ConnectorAuthNotes
Jamf ProOAuth client credentialsThe most capable. Supports smart group pull for loan pools
Microsoft IntuneOAuth client credentialsVia Microsoft Graph
KandjiAPI token
MosyleAPI tokenManager and Business. Common in Apple-heavy schools
Chrome EnterpriseService accountChromebooks, via the Google Admin SDK
Mock MDMAnyFor demos and tests
ConnectorAuthNotes
SynergeticAPI tokenCommon in independent schools. Reaches a private network
SentralAPI key plus tenant keyWidespread in New South Wales
Compass EducationService account credentialsDominant in Victoria
ConnectorAuthNotes
LDAP and Active DirectoryBind accountAuthenticate, look up, reset passwords. Reaches a private network
Directory managementClient credentialsLicences, lock, inbox delegation, password reset
ConnectorAuthNotes
SMTPUsername and passwordAny SMTP server. The simplest option
Google WorkspaceService accountSends via the Gmail API with delegation
Console emailNoneLogs instead of sending. Development only
TwilioAccount SID and auth tokenSMS
ConnectorAuthNotes
ZendeskAPI tokenCreate, comment on and close tickets
Web Help DeskAPI keySolarWinds. Reaches a private network
ConnectorAuthNotes
Apple GSXAPI tokenWarranty and AppleCare coverage
Dell warrantyClient credentialsEntitlement by service tag
CompNowAPI tokenLodge external repairs and sync status
ConnectorAuthNotes
Printers over SNMPNoneToner, status and errors. Reaches a private network
PaperCutAuth tokenBalances, page counts, and writing the tap card. Reaches a private network
ConnectorCategoryNotes
ThreatLockerSecurityEndpoint allowlisting approvals
SalesforceCRMAccounts, contacts and cases
Google SheetsSpreadsheetInduction roster import
OllamaAIThe assistant, on a model you host
StripeBillingSubscriptions and metered billing

More than one MDM. You can configure several, and a device resolves through whichever one knows it. That is genuinely useful in a mixed fleet: Jamf for Macs, Intune for Windows, Chrome Enterprise for Chromebooks.

More than one SIS. Unusual, but supported. Rosters merge and people are de-duplicated.

Email. Pick one. SMTP is simpler and works with anything. Google Workspace sends as a real mailbox in your domain, which some schools prefer for deliverability.

Ticketing. If you already run Zendesk or Web Help Desk, connect it and switch off the built-in module.tickets. Running both queues means work gets lost between them.

Most connectors have a demo mode that returns realistic fictional data instead of calling the real system.

Turn it on to see a feature work before credentials arrive, then turn it off. Leaving it on in production is the most common configuration mistake in the product. The compliance page counts connectors still in demo mode, precisely so it gets noticed.

Some connectors talk to something that normally lives inside a school network: Active Directory, a Synergetic SQL Server, PaperCut, a printer answering SNMP, Web Help Desk.

A self-hosted install on that network reaches them directly and needs nothing extra.

A managed deployment cannot, and uses a connector agent: a small program installed inside your network which dials out, collects queued work and returns results. No inbound firewall rule.

Note the framing: whether an agent is needed depends on where the deployment runs, not on the connector.

Connector credentials are protected with envelope encryption. They are encrypted before they reach the database and decrypted in memory only for the duration of a call. A connector handler never gets database access; it returns data and the platform decides what to persist.

The master key is SECRETS_MASTER_KEY. See secrets and keys.