Configuring a connector
Admin, Connectors (/admin/connectors), gated by the connector.manage
permission.
The steps are identical for every connector. The vendor-specific part is getting the credentials, and that is on each connector’s own page.
The steps
Section titled “The steps”- Find the connector under its category and click Configure, or Reconfigure if it already has settings.
- Fill in the settings. Non-secret fields such as a URL sit in one section; credentials sit in another and are write-only once saved.
- Click Save and test. Plugboard saves the settings and immediately verifies the connection, reporting success with a latency, or the error the system returned.
If the test fails, nothing about your existing configuration is lost. Fix the value and test again.
Settings against secrets
Section titled “Settings against secrets”Every connector separates them.
Settings are things like a base URL, a tenant id, a mailbox address, a customer id. They are stored as ordinary configuration and shown back to you.
Secrets are tokens, passwords and private keys. They are encrypted with envelope encryption before they touch the database and never displayed again. The form shows them as set, and leaving a secret field blank when re-saving keeps the existing value.
That last behaviour matters: you can change a base URL without re-entering a token you no longer have a copy of.
Demo mode
Section titled “Demo mode”Most connectors have a demoMode switch. With it on, the connector returns
realistic fictional data and makes no calls to the real system.
Use it to:
- See a feature work before the credentials arrive.
- Demonstrate the product without wiring up a school’s real systems.
- Set up training environments.
Then turn it off. A connector left in demo mode in production looks like it is working and is not, which is a worse failure than one that is obviously broken.
The compliance page lists connectors still in demo mode, for exactly this reason.
Testing
Section titled “Testing”Save and test runs the connector’s own health check. Each connector defines what “working” means for it, which is usually the cheapest authenticated call the vendor offers:
- Jamf authenticates and pings.
- Intune requests a Graph token.
- LDAP performs a bind.
- SMTP opens a connection and authenticates.
- Kandji lists one device.
The result includes latency. A test that succeeds in 3 seconds is telling you something about how the feature depending on it will feel.
More than one instance
Section titled “More than one instance”You can configure more than one instance of the same connector. A school with Macs in Jamf and Windows machines in Intune configures both, and a device resolves through whichever knows it.
The same applies within a category: two MDMs, two SIS connectors, two ticketing systems. The platform picks an enabled instance implementing the capability.
Disabling against deleting
Section titled “Disabling against deleting”Disabling an instance stops it being used but keeps the configuration and credentials. Use this to test what happens without a connector, or to pause an integration during a vendor outage.
Deleting removes the configuration and the encrypted secrets. The credentials are not recoverable afterwards.
What connecting something changes
Section titled “What connecting something changes”Connectors light up features elsewhere. Configuring one is usually the answer to “why is this screen empty”.
| Connect | And you get |
|---|---|
| An MDM | Live device details, MDM actions on the device page, serial autocomplete, loan pools pulled from smart groups |
| An SIS | People, year levels, tutor groups, card numbers, term dates |
| A directory | People, and directory account management |
| Every notification, tracking link, receipt, alert and scheduled report | |
| SMS | Text notifications |
| A ticketing system | External ticket sync from submissions |
| Warranty | Coverage lookup on a device, feeding the coverage on a repair |
| A repair vendor | Vendor repairs booked out from a submission |
| Printers | The printer fleet page |
| PaperCut | Balances and card writing |
| ThreatLocker | The security approvals queue |
| Ollama | A smarter assistant |
When the test fails
Section titled “When the test fails”Work through these in order. They cover most of it.
| Check | How |
|---|---|
| Is the URL right, including scheme and no trailing slash | Paste it into a browser |
| Is the credential the value rather than the id | The single most common mistake with Entra client secrets |
| Has the credential expired | Most vendors expire tokens. Some do it silently |
| Does the account have the permission the connector needs | Each connector page lists the minimum |
| Can the server reach it at all | curl from the server, not from your laptop |
| Is it a private address | A managed deployment needs an agent; a self-hosted one may need ALLOW_PRIVATE_EGRESS=1 |
| Is a proxy or firewall in the way | Outbound filtering on school networks is common and usually silent |
The error message on the test result is the vendor’s own, not ours. It is generally worth reading literally.
Auditing
Section titled “Auditing”Configuring, reconfiguring, enabling, disabling and deleting a connector are all written to the audit log, with who did it and when. Secret values are never written to the log.