Integrations

Admin › Account › Integrations connects schoolOS to the systems your district already uses, so devices, people and help articles come in on their own instead of being typed in.

You need Manage integrations to use this page.

The list#

Every integration has its own article with the whole of how it works: select How it works on its row here, or Learn more on its setup page.

Integrations you've connected come first, under Connected; the rest are grouped by what they bring in: Device management, User management, Roster, Payments (MySchoolBucks), Smart lockers (LocknCharge), Knowledge and Calendars, with Coming soon last. Each row shows the logo and what it does. Use Search integrations to find one by name, or Filter › Category to show one group (the connected ones in it stay on top). The count at the top right says how many are connected.

The right end of each row says where it stands:

• + opens that integration's setup page. It isn't connected until you finish setup there.
• Connected, with a ⋯ menu: Manage opens the setup page, and Disconnect asks you to confirm, then disconnects it. See Disconnect an integration.
• Coming soon isn't available yet.

Selecting anywhere on a row opens its setup page.

The integrations under Coming soon can't be turned on yet: Microsoft Configuration Manager, Meraki and FileWave. Their pages show what a connection will need.

Device management (MDM)#

These bring your devices into schoolAssets and keep their details current. Each sync matches a device to an existing asset, by its device ID and then its serial number, before creating anything new (see How a device is matched). You can also connect them, see whether each is connected and run Sync now from the Assets tab of Admin › Account › Import Data, at the top above the CSV import. See Connect a device management system.

• Google Devices. Chromebooks and other ChromeOS devices. See Google Devices. Sign in with a Google Workspace super admin account. Before you connect, decide on Allow schoolOS to manage devices (see Read only or two-way). The connection also asks for Chrome Management telemetry, which Device Health reads for battery, update, memory and temperature checks; turn the telemetry reporting policy on in the Google admin console for the devices' organizational units, and if you connected before telemetry was asked for, select Reconnect for telemetry on the setup page.
• Jamf Pro. Macs, iPads, iPhones, Apple TVs and Apple Watches. See Jamf Pro. Enter your Jamf Pro server URL, then sign in with an API client (a client ID and secret) or a Jamf Pro username and password.
• Microsoft Intune. Windows, iOS and Android devices. See Microsoft Intune. Sign in with your Microsoft Entra ID account.
• Mosyle. Apple devices. See Mosyle. Choose Mosyle Manager (the education product most districts use) or Mosyle Business, then paste an Access token from your Mosyle admin console.
• PDQ Connect. Windows devices, with their software, Windows updates and vulnerabilities, from one or more PDQ organizations. See PDQ Connect. Add each organization with its Organization URL and an API key made for schoolOS; schoolOS checks what the key can do and lists the scopes to add for what it can't.
• Apple School Manager. Every Apple device your district bought, with its order details and AppleCare coverage. It isn't an MDM: it adds a source to the Assets import and keeps AppleCare current on the devices you have. Enter the Client ID and Key ID of an API account and upload its private key. See Apple School Manager.

Secrets and tokens are stored encrypted and never shown again. To keep the current one when you edit a connection, leave its box blank.

Each setup page leads with whether it's connected and, once it is, Sync now. Once connected, the page offers:

• Asset identifier matching (Jamf Pro, Google Devices and Intune). How a device is tied to an existing asset when the serial number alone doesn't match: which schoolOS field (Serial Number or Asset Tag) to compare with which field in the other system.

• What to do with devices schoolOS doesn't have. When a device in the other system matches no asset (Jamf Pro and Google Devices offer a choice; Intune and Mosyle only count them):

  • Jamf Pro: turn on Create the asset to add it automatically, or Queue it for review instead so nothing is created until someone approves it. With both off, it's skipped.
  • Google Devices: choose Do nothing (log only) (the default), Add to review queue (IT approves each one before it becomes an asset) or Auto-create. The Review queue is on the same page: select a device's ... menu to Approve or Reject it, tick several to approve them together, or select Approve all.

  Assets are never deleted when a device leaves the other system: a device can drop out for a repair or a move, and deleting would lose its history.

  | Option | What happens to a new device | Choose it when | | --- | --- | --- | | Do nothing / both off | Logged and skipped. | You add assets another way, like an import from your purchasing records, and the MDM only fills in details. | | Add to review queue / Queue it for review instead | Waits until someone approves it. | Your first sync, or an MDM that also holds staff-owned or test devices you don't want as assets. | | Auto-create / Create the asset | Becomes an asset straight away. | Your MDM is the list of record, like a Chromebook 1:1 program where every enrolled Chromebook is district property. |

  For example, a district enrolling 4,000 student Chromebooks imports its purchase spreadsheet first, then connects Google Devices with Add to review queue. Chromebooks that match by serial number get their details filled in. The 40 that don't wait in the queue, where IT spots a few spares that were never on the spreadsheet and approves them.

• Field mapping. Where each field from the other system lands in schoolOS, including your own custom asset fields. Search the fields, or filter them by group or by whether they sync. Tick a row to sync it, choose the schoolOS field, and pick the direction: into schoolOS, or back out to the other system where it accepts changes. Everything the other system reports shows on each device's MDM section whether or not it's mapped; mapping is what makes a field filterable, reportable and usable in workflows. A row that schoolOS fills in another way says so in place of the picker (Google's Auto-Update fields are read through Support End Date (AUE), and its Last Known Network is saved to Last WAN IP on every sync). A row with a default that isn't chosen shows Default under the picker, with Use default; Reset to defaults on the Google Devices page puts every row back.

  A new connection starts with sensible defaults, and a few are worth knowing:

  • Google Devices fills Support End Date from the Chromebook's Auto Update Expiration (reading autoUpdateThrough first, then the older autoUpdateExpiration, then supportEndDate), MAC Address from the Wi-Fi MAC, and OS Version from the Chrome version. The org unit path, the platform version and the enrollment status aren't mapped by default: an org unit like /Students/Grade 5 is rarely a building, and ACTIVE or DEPROVISIONED isn't a lifecycle status. See Support End Date and Warranty Expiration.
  • Microsoft Intune fills Assigned To (Email) from the user's email address, or the user principal name only when that is an email address. Enrolled Date/Time fills Deployed Date only while it's empty, since re-enrolling a device moves the date. Compliance state isn't mapped to the asset status.
  • Jamf Pro fills MAC Address from the computer's or iPad's Wi-Fi MAC, Last WAN IP from the address the Jamf server last saw the device from, and, when you turn the purchasing fields on, Purchase Date from the PO date and Warranty Expiration from Jamf's warranty date.
  • Status, Location, Room, Model and Manufacturer are matched to a record you have, by name (or a location's code or abbreviation), and written together with it. A value nothing matches is skipped, and the sync's log says so, rather than stored as loose text. A date the other system sends in a shape the field can't take is skipped the same way.
  • A field with two provider fields pointed at the same schoolOS field keeps whichever the sync reads last. Map one.

• Device sync. When the last sync ran and how it went. Sync now runs one right away and reads everything the other system has.

  The nightly sync keeps its own work small. Google Devices and Microsoft Intune are asked only for the devices that checked in since the last successful sync; once a week, after a failed sync, and whenever you select Sync now, everything is read again, so a device that was retired or edited in the other system's console without checking in is still picked up within the week. Jamf Pro and Mosyle are read whole every night. PDQ Connect is asked for what it updated since, like Google and Intune, and can be set to sync once a week or only on Sync now. Either way, a device whose record hasn't changed since the last sync is skipped: nothing is written to it or its asset, its modified date and activity stay as they were, and the sync's summary says how many were skipped as unchanged. Changing a field mapping or a matching setting makes the next sync apply it to every device once.

Once a connection is set up, its sections fold closed and show their current setting, so the page reads as a summary. Open the one you need.

How a device is matched#

The device ID your device management system gives each device is what tells devices apart. Serial numbers can repeat: a replaced motherboard, an imaging tool, or the same laptop in two systems. So two devices with the same serial become two assets, and nothing is ever written onto the wrong one.

Each sync looks for a device's asset in this order:

1. Its device ID. Once a device is linked to an asset, it stays linked, whatever its serial says.
2. Its serial number, only when that points at one asset without guessing:
   • One asset has it and no other device from the same system is linked to it: the device links to that asset.
   • The same device in two systems (for example Intune and Google Devices): both link to one asset. Each system fills in its own fields. When both report the same kind of field, like OS version or last user, the one that reported most recently wins. The asset's MDM tab shows each system's values, with a button for each.
   • A new device ID, and the old one is gone (the device was re-enrolled): the link moves to the new ID. The asset keeps its history, and its timeline says "Re-enrolled in Google Devices: device ID changed". A device only counts as gone after a sync that read the system's whole inventory and didn't find it. If part of the inventory couldn't be read, the device waits in review instead.
   • Both device IDs are still reported: they're different devices. The new one gets its own asset when Auto-create is on, and waits in review otherwise.
   • More than one asset has the serial: the device waits in the review queue as Duplicate serial.
3. Its asset tag, when Asset identifier matching compares the asset tag, by the same rules.

Placeholder serials never match. Some devices report a stand-in instead of a serial, like "To be filled by O.E.M.", "Default string", "System Serial Number", "None", "N/A", "0", "123456789" or all zeros. These are treated as no serial: the device is matched by its device ID (or asset tag), a new asset is keyed on the device ID and doesn't take the placeholder, and the asset's MDM tab shows No real serial. Placeholders never count as duplicates anywhere in schoolOS.

Duplicate serial in the review queue. The item lists the assets with that serial, each linked. In its ... menu, choose Link to one of them, or Create a separate asset when it's a different device. Linking to an asset another device from the same system holds moves that link to this device. Approve all leaves these items for you to decide.

Device sync sums up each run, including duplicates: how many devices were re-enrolled, linked across systems, added as separate devices, or sent to review.

Manufacturer names#

Device management systems spell the same manufacturer many ways: "Dell Inc.", "DELL" and "Dell"; "HP Inc." and "Hewlett-Packard"; "LENOVO"; "ASUSTeK COMPUTER INC."; "Microsoft Corporation"; "Acer Inc."; "Apple Inc.". Every device sync, from any system, reads them as one manufacturer before it looks in your catalog, so one manufacturer stays one entry and its models stay together:

• A manufacturer already in your catalog under any of its spellings is used as it is. If you have Dell Inc., Dell devices go there; no Dell is added beside it.
• A manufacturer that isn't in the catalog yet is added under its plain name: Dell, HP, Lenovo, ASUS, Microsoft, Acer, Apple, and the like. A name schoolOS doesn't know is added as the system spells it.
• Nothing already in your catalog is renamed or merged. To tidy entries added before this, rename or merge them in Admin › Assets › Manufacturers.

Read only or two-way#

Jamf Pro. Read only pulls devices into schoolOS and never writes to Jamf. Two-way also sends the asset tag, assigned person, room and purchasing details back to Jamf on each sync, and lets you send device commands, like Lock Device, Restart Device and Erase Device, from a device's page. Two-way only fills in fields schoolOS has a value for; it never blanks a field in Jamf. Pick read only unless you want schoolOS to be where you keep those details.

Google Devices. When you connect, the Allow schoolOS to manage devices switch decides what the connection may do:

• Off (read only). schoolOS reads your Chromebooks and changes nothing in Google.
• On. Workflows can also disable a Chromebook and update its annotated user, location, asset ID and notes in Google, for example disabling a Chromebook when it's marked lost. Workflows that need it are skipped on a read-only connection.

Turn it on only if you use workflows that change Google or want the device actions below. To add it later, select Enable and reconnect beside Device management; your devices and sync history stay. The Remote device actions section shows which you have: Device management on or Read only, and what workflows can do with it.

With device management on, a Chromebook's page offers Google's device actions at the bottom of its MDM section: Request Remote Session, Reboot Device, Disable Device, Re-enable Device, Wipe Users, Powerwash Device and Deprovision Device. Each opens a dialog that says what it does and sends it when you confirm, then reports whether Google queued it or refused it (a connection without device management, say) until you close it; the ones that erase data also ask you to type the asset tag first. Each is applied when the device is online. Request Remote Session opens a Chrome Remote Desktop session so you can see and control the screen: the Chromebook has to be online, someone signed in sees that an administrator is connecting, and the link Google returns lasts a few minutes. The same action sits under Actions on a device linked to a ticket, so a technician can look at the screen from the ticket. Moving a Chromebook to another organizational unit is still done in the Google Admin console.

Intune and Mosyle are read only. Remote actions like wipe or lock aren't available for them.

User management#

• Google Workspace and Microsoft Entra ID. Bring staff and students in from your directory, with the role and school your rules give their org units and groups, and keep them in step every night. See Directory sync for the rules, and Google Workspace directory or Microsoft Entra ID directory for each connection.

Roster#

• Universal Roster Integration. Keeps your staff and students in step with your student information system, over the OneRoster API or a file dropped on SFTP. The card opens the People tab of Admin › Account › Import Data. See Import people.

Knowledge#

These bring documents and help articles into the knowledge base that schoolAgent and Otto answer from. Nothing is ever written back.

• Google Drive and Microsoft OneDrive. See Google Drive and Microsoft OneDrive. Each person connects their own account, and sees only the drives and folders they can already open. Access is read only. After connecting, choose what comes in from the Knowledge tab (Add documents in Knowledge): folders and files at any depth, in My Drive or a shared drive. The Google Drive setup page's own Shared drives and folders list shows only shared drives and their top-level folders, and once anything has been chosen in Knowledge it no longer changes what syncs. Each setup page lists everyone whose account is connected under Google Drive connections or OneDrive connections, so you can see whose files are syncing.
• Zendesk. See Zendesk. Enter your Zendesk subdomain, an Agent email and an API token. Then pick the Help Center sections to bring in under What to bring in, and select Save selection. schoolOS sees exactly what that agent can see.
• Freshservice. See Freshservice. Enter your Freshservice domain and an API key (or use the one saved for ticket import), then pick the sections to bring in.
• Freshdesk. See Freshdesk. Enter your Freshdesk domain and an API key, then pick the sections to bring in.
• Confluence and HappyFox. See Confluence and HappyFox. Select Add source, connect, then choose the spaces, pages, sections or articles to bring in. You can add several sources, for example one for IT and one for the district.

Each one has How often: bring what you chose in Once, or Keep in sync hourly, daily, weekly or monthly. It's the same setting, with the same choices, on its setup page, on the Knowledge tab of Admin › Account › Import Data (which opens the same setup page) and on the Knowledge page. See Once, or keep in sync?.

For Zendesk and Freshworks, articles the help desk restricts (a Zendesk article limited to a user segment, or a Freshdesk folder narrower than everyone) come in as internal, visible only to signed-in staff.

Calendars#

• Google Calendar and Outlook Calendar. Connect your Google or Microsoft account and share calendars it can reach, like a team out-of-office calendar, with chosen departments and teams. Each has its own page, where you connect accounts and share calendars; once an account is connected, its row shows Connected and its menu offers Manage. See shared calendars.

Disconnect an integration#

Open the ⋯ menu on the integration's row and select Disconnect, or use Disconnect on the setup page. Either way, you confirm first.

What it does:

• Syncing stops, and the saved sign-in details are cleared. To reconnect, you set it up again.
• MDM: your assets stay, with the details already synced onto them.
• Confluence and HappyFox: the documents that source brought in leave the knowledge base, and schoolAgent stops using them. From the list, HappyFox disconnects every source you added; to drop one, use Disconnect on its card.
• Zendesk and Freshworks: the articles already synced stay in the knowledge base until you remove them there.
• Google Drive and OneDrive: the documents already imported stay in the knowledge base until you remove them there.
• Nothing changes in the other system.

Syncs and their errors are listed on the Integrations tab of Admin › Account › Logs.