Before a Chromebook reaches a student.

1. Agree ownership and the release conditions

Name a deployment owner, a school contact and the person who can approve exceptions. Separate receiving equipment from accepting it for teaching. Record model, serial number, asset tag, intended school, spare allocation and the approved lifecycle plan.

Confirm the required Chrome management entitlement, the account allowed to enrol devices and the intended organisational unit (OU). Decide which settings belong to the device and which follow the signed-in user. A staff test account cannot demonstrate that a student’s policies work.

2. Confirm enrolment and policy placement

Google requires enrolment before the first user signs in for the standard manual enrolment process. At initial setup, use the district’s approved enrolment method; where applicable, Ctrl + Alt + E opens enterprise enrolment. Check the device’s serial number in Google Admin console → Devices → Chrome → Devices and confirm the intended OU. Do not assume that the account used for enrolment automatically places it correctly. Google’s enrolment instructions explain the prerequisites and current options.

If someone has already signed in before enrolment, stop and follow the district’s approved recovery procedure and Google’s instructions. A wipe removes local data; it should not be an improvised response to every setup error.

Review the effective forced re-enrolment setting with the management owner. It is intended to keep wiped devices under management. Retirement, resale and transfer need a deliberate deprovisioning process. Check the model and deployment method against Google’s forced re-enrolment guidance.

3. Run a student’s school day on the pilot

Use authorised test accounts and synthetic records. Record pass, fail or not applicable, with a reason and an owner. The following is a suggested acceptance checklist for your local plan, not a claim that every district needs identical settings.

1. Sign in: the intended student can sign in; an account outside the permitted audience behaves as district policy requires.
2. Policy: the correct restrictions, approved extensions and applications appear for the intended device and user.
3. Teaching: open the learning platform, create and submit a test assignment, and use required audio, camera or printing features.
4. Accessibility: test the adjustments and assistive tools the student actually needs, with the relevant school specialist.
5. Filtering: use the district’s approved test destinations on the school network and, for take-home devices, an approved off-site connection. Record the expected outcome and reporting route.
6. Assessment: have the assessment coordinator validate the current testing provider’s requirements, supported versions and any dedicated test mode. A normal browser session is not sufficient evidence.
7. Shared use: sign out and use a second test account. Check that the next user cannot see the previous user’s locally exposed work.
8. Recovery: try the support and loan-device process with a test incident. Confirm that families and school staff know whom to contact.

Keep student privacy approval separate from a successful login

Before adding an educational service or extension, record what student information it receives, why it needs it, who receives it, retention and deletion arrangements, and the district approval. Refer questions about FERPA and other applicable requirements to the district’s student privacy lead. The US Department of Education’s online educational services guidance is a starting point; state requirements, contracts and district policies also need checking.

For services involving children under 13, ask the privacy lead to check the operator’s COPPA arrangements and the limits of any school authorisation. A school account is not a blanket permission for commercial use of children’s information. See the FTC’s COPPA guidance.

4. Worked example: the app appears for staff, but not students

Illustrative case. A district is preparing a Chromebook batch for a middle school. A technician signs in with a staff account and the required learning application opens. During the student pilot, it is missing.

The team records the device serial number, device OU, student test account’s policy group and the missing application. They compare the effective assignments with a working student device. The application was assigned to the staff group used for the initial demonstration. The application owner corrects the intended student assignment in the pilot, then the team repeats the student task and checks the result.

The lesson is a concrete release rule: every required classroom application needs evidence from the intended student context. A successful administrator or staff demonstration does not meet that rule. Keep the rest of the batch on hold until the relevant student checks pass.

5. Release the batch with a support record

Record the pilot devices and accounts, test date, policy baseline, open issues, accepted limitations and the approving owner. For the batch, reconcile serial numbers and school allocations, then verify management and policy placement using the district’s agreed quality checks.

Provide a short school-facing handover: how students sign in, where to report faults, how to obtain a loan device, what families should do if a device is lost, and when the first follow-up review will happen. Keep technical inventories and student information in the district’s approved systems.

If a required control fails, record the exception and owner before release. Do not let the delivery deadline silently become the approval. Use the downloadable checklist for the next model, school or year-group rollout.