Words we use
Most of these are ordinary words. They are listed because a few of them mean something specific in Plugboard, and because reading a page that uses “person” and “user” as different things is confusing until you know why.
Tenant. One institution. A self-hosted install has exactly one. A managed deployment has one per customer, and a multi-campus customer can have several. Every record in the database belongs to a tenant and cannot be seen from another.
Person. A student, staff member or parent. People are synced in from your student information system and directory, not typed in. A person does not sign in to the console. They tap a card at the kiosk or sign in to a portal.
User. Somebody with a Plugboard account who signs in to the technician console. Almost always ICT staff. Users have roles; people do not.
Module. A feature that can be switched on or off for your institution, keyed
as module.something. Turning one off removes its navigation and stops its
endpoints answering. See modules.
Permission. A fine-grained right such as loan.issue or charge.approve.
Permissions are granted through roles. See
permissions.
Connectors
Section titled “Connectors”Connector. An integration definition: a category, an authentication kind, a configuration form, a secret form, and a list of capabilities. Jamf Pro is a connector.
Connector instance. A connector you have configured, with your URL and your credentials. You can have more than one instance of the same connector.
Capability. A named operation the platform can ask for, such as
device.lookupBySerial. Features depend on capabilities, never on vendors, which
is what makes swapping an MDM a configuration change. See
capabilities.
Demo mode. A per-connector switch that makes it return realistic fictional data instead of calling the real system. Useful before credentials arrive, and a mistake to leave on.
Connector agent. A small program installed inside your network so a managed deployment can reach systems that are not on the internet. It dials out; nothing dials in. See connector agents.
Submission. A repair. Somebody’s device needs work, and this is the record of it: the device, the problem, the person, the status, the cost. Named “submission” rather than “repair” because the original system called it that and schools kept using the word.
Ticket. Work that is not a device repair. A fault, a request, a question. Tickets have categories, queues and canned responses; submissions have devices and repair types. They are separate modules and either can be switched off.
Repair type. What kind of repair it is, defined by you. Each carries a coverage.
Coverage. Who pays: warranty, insurance, or chargeable. It appears when the person lodges, and it is how cost analytics splits spending.
Loan. A spare device lent to somebody, usually while theirs is being repaired. Loans have numbers, live in groups, and can be pulled automatically from an MDM smart group.
Loan group. A pool of loan devices with its own kind and numbering, such as Loan Laptops or Staff Loaners.
Charge. What a family is being asked to pay for a repair. Raised by one person, approved by a different one, on purpose. See damage charges.
Induction. A bulk device handout, usually at the start of a year. A roster is imported, students are tracked through it, and each one’s issued device is recorded.
Stocktake. A physical audit. Work through a location scanning serials and find out what is actually there.
Service quality
Section titled “Service quality”SLA. Response and resolution targets per priority. Breaching one flags the submission and raises an alert. See service levels.
CSAT. The one to five star rating a person can leave on the tracking page after their repair closes. See satisfaction ratings.
Monitor. A scheduled check on a service you care about: an HTTP endpoint, a TCP port, a TLS certificate expiry, a ping, or the heartbeat of a connector agent. See monitors.
Automation rule. A when-then rule evaluated when a submission is created. Conditions match on type, priority or coverage; actions set a priority, assign a technician, or notify. See automation rules.
Deployment
Section titled “Deployment”Deployment. One running instance of Plugboard. Has an id, a region, a version and a release channel. The unit that gets updated, backed up and billed.
Ring. How far through the release schedule a deployment sits. Ring 0 is our own instances, ring 1 is consenting early customers, ring 2 is everyone else.
Channel. stable or beta. Determines which release we recommend to a
deployment. It never causes an automatic update.
Control plane. The vendor-side console: customers, licences, deployments, telemetry and billing. It holds no customer content, only counts. Never shipped to a customer. See the control plane.
Licence. An Ed25519-signed token that states a plan, a tier and its limits. Verified locally and offline by the instance, so a network outage never disables a service desk.
Telemetry. Count-only usage a deployment reports to the control plane: how many technician accounts, how many managed devices, which modules are on, what version. No names, no records, no content.
Security
Section titled “Security”Secrets vault. Envelope encryption over connector credentials. They are encrypted before they reach the database and decrypted in memory only for the duration of a call.
SECRETS_MASTER_KEY. The key that encrypts the vault and your backups. A
database restored without it cannot decrypt its own secrets. Keep a copy
somewhere other than the server.
RLS. PostgreSQL row-level security, the database-level enforcement of tenant isolation. See tenant isolation.
Audit log. Append-only record of every action, with configurable retention. See the audit log.