School departments (beta preview)
Departments extend the existing Tickets workflow to other school teams. A room fault, office enquiry and ICT request use the same ticket numbers, conversation, attachments and audit history, with access controlled for each department. Department membership does not grant access to device or identity administration.
Enable the add-on
Section titled “Enable the add-on”Keep Tickets enabled. In Admin, Features, enable the add-on your school is entitled to use:
| Add-on | Module key | Intended work |
|---|---|---|
| Facilities | module.facilities |
Building faults, maintenance and room requests |
| Administration | module.administration |
School office enquiries and document or event support |
| Other departments | module.departments |
Other named school teams using configured request forms |
These add-ons require explicit activation and entitlement. They are not enabled by an existing broad licence or a missing feature setting. Confirm the licensed modules for your school; this guide does not assign a price or plan tier.
The deployment must also have the department database migration, restrictive ticket policies and a restricted application database role installed. Creation is refused when the database can bypass those controls. A self-hosting operator should complete the release’s installation checks before configuring desks.
Create a department
Section titled “Create a department”Open Admin, Service delivery, Departments (/admin/departments). The
departments.manage permission is required. This is school-wide administration,
so give it to the people responsible for access across departments. Campus
restrictions continue to apply.
- Choose Add department, then enter its name and add-on type. An existing department’s type cannot be changed.
- Write a short description requesters can recognise, and optionally a default queue. A queue organises work inside a department; it does not grant access.
- Configure the services and questions described below.
- Leave Department accepts new requests enabled and save.
- Choose Manage members and add the staff who should work there.
Use an Inbound email address only when that exact address is delivered to the configured ticket mailbox. A new message to that address routes to the department. Multiple matching department destinations are refused; unmatched messages follow the existing ICT intake. Replies continue on their existing ticket. This field does not create a mailbox or configure mail forwarding.
Keep request forms short
Section titled “Keep request forms short”A service can ask for a short answer, long answer or choice from a list. Mark a question required when the team cannot act without it. For example, a Facilities service named Room fault could ask for the room number and fault type. The requester can also enter a building or location without choosing an ICT device.
The editor supports up to 20 services per department and 12 questions per service. Choice lists allow up to 30 options. A request selects a service when the department offers services and must answer that service’s required questions. Changing department or service clears answers to the previous form.
New requests keep the submitted service name and question labels alongside their answers. Editing a form or transferring the ticket does not rewrite those labels. Older tickets without that snapshot show their stored question keys as readable labels. Avoid reusing a removed question for a different meaning.
Assign staff access
Section titled “Assign staff access”Membership and permissions serve different purposes. Membership chooses which
department a staff member can access. Their role still needs the relevant
ticket.view, ticket.create, ticket.update, ticket.comment, ticket.internal
or ticket.close permissions for the work they do.
Existing staff keep access to the original ICT service desk unless you explicitly change it. To make an account Facilities-only, add it to Facilities and select Restrict to assigned departments (remove legacy ICT access). That checkbox affects the person’s ticket access across the school, not only the department currently being edited. Review their other memberships first. A staff account with that restriction and no memberships has no department access.
The departments.manage permission grants broad department administration;
do not put it on a role intended for a single department worker. Being an
assignee or staff watcher does not grant department access. Requesters still see
their own public conversations across departments, and deliberately nominated
external watchers retain the existing public correspondence behaviour.
The membership editor shows up to 500 active staff accounts. If the school has more, saving is disabled to avoid removing members who are not in that list. Resolve this limit with your deployment administrator before changing membership.
Pause without losing history
Section titled “Pause without losing history”Turn off Department accepts new requests to pause a department. Disabling its add-on also prevents new intake and operational changes. Existing tickets, answers, attachments and memberships are retained under their access controls.
Pausing cancels pending recurring work and disables its schedules. Re-enabling a department does not replay missed occurrences or automatically restart schedules. Review and explicitly re-enable the schedules that should resume. Rules cannot run or dispatch actions while their department or add-on is paused.
Recurring maintenance and rules
Section titled “Recurring maintenance and rules”Under Admin, Service delivery, Tickets, create a ticket template, select its department, enter Building or room, and describe the work in the body. Then create a schedule using that template. The current recurring-work editor uses the template body and location; it does not fill in a department service form. Create a new template to change its department.
Recurring schedules need a single-campus staff scope or unrestricted campus access. The schedule editor currently has no separate campus picker. Creating or enabling a schedule is refused when its resulting scope contains several campuses; ask your school administrator to use a suitable campus scope. A saved single-campus schedule stays limited to that campus when its owner gains access to others. You can still disable schedules without resolving a campus conflict.
Ticket rules also select a department. Existing rules belong to ICT. Preview
checks up to 500 recent eligible tickets in the selected department and never
executes the rule. An action queued before a ticket transfers is refused if its
originating department no longer matches. Shared ticket settings and action
definitions remain school-wide. Once any department exists, including a paused
one, changing shared replies, reply-mailbox settings, label definitions, routing,
classifier rules, reopen policy, workflow
catalogues, SLA policy or automation caps requires departments.manage alongside
the setting’s existing permission. This does not prevent a department workflow
manager from maintaining scoped rules, templates and schedules. See
ticket settings.
Assigning an existing label to an accessible ticket continues to use normal ticket permissions; creating, renaming or deleting the shared label definition is a school-wide configuration change.
Department ticket events are withheld from generic outbound webhooks until endpoint-specific department scopes are available. Existing integration API keys remain limited to ICT. Do not plan a department integration around an unrestricted key or webhook.
Merging and unmerging tickets require the same department, including any merged conversation history. When work belongs elsewhere, use an authorised department transfer first. Ticket SLA alerts are limited to staff with current department access and do not dispatch while the department or add-on is paused.
When something does not work
Section titled “When something does not work”| Symptom | Check |
|---|---|
| Departments is missing | Installed release, Tickets module and departments.manage permission |
| Add-on is inactive | Explicit module activation and the school’s licence entitlement |
| Department creation is refused | The release migrations, ticket policies and restricted database role |
| A worker sees ICT requests | Their legacy-access restriction and whether their role grants broad department administration |
| A worker sees no requests | Membership, ticket permissions, campus and selected filters |
| A department is absent from a new request | It may be paused, unentitled or outside the staff member’s membership |
| Recurring work did not restart | Review and re-enable its schedule after restoring the department |
| Membership cannot save | More than 500 active accounts, or an unavailable member needs review |
For everyday intake and transfers, see working across school departments.
Back up the whole school
Section titled “Back up the whole school”Backups include all campuses, ICT and configured departments, including paused
history. Backup permissions alone do not grant access to that combined data:
accounts need unrestricted campus access and departments.manage whenever any
department exists. Scheduled backups use a separate trusted whole-school context.
New v3 archives restore paused departments and their history together in one transaction, keeping those departments paused afterwards. Earlier unmarked archives cannot be restored from the application; an operator must validate them in a maintenance workflow, even if the archive came from an ICT-only school. See backup access and compatibility.