A systems administrator’s guide to digital signage for schools

Every piece of hardware or software with access to a school’s network is a security disaster waiting to happen. Students plug USB drives from home into library computers. Teachers convert classroom documents into new file formats using shady websites. And everyone expects you to fix their problem ASAP. 

For many admins, rolling out digital signage doesn’t just feel like a low priority. It feels like a step backward. More endpoints to manage and more SaaS accounts to monitor. With a bit of planning, though, you can shrink the attack surface and minimize the impact of digital signage on your school’s helpdesk.

Admin-approved hardware and software for digital signage

Obviously, the most secure solution would be an air-gapped screen where you update content locally. Not exactly a viable solution when the goal is multiple with daily or even weekly updates. While pushing content to screens over the network shouldn’t jeopardize FERPA or COPPA compliance as long as it doesn’t include students’ personal information, any Wi-Fi or LAN-connected TV or LED screen is a potential stepping stone to devices that do store sensitive data.

You might be able to get away with connecting your screens to a small-profile computer like Apple’s Mac Mini or a USB media player like Amazon’s Fire TV Stick, isolating them on a VLAN, and playing a looping Google Slides presentation. It’s a little hacky, but would at least prevent bad actors from moving laterally across the network if the device were compromised. Another option would be running the free and open-source digital signage app Xibo CMS on a campus server if you’re comfortable with Docker.

For more purpose-built hardware, there’s the Station P1 Pro, which supports secure network configurations, proxies, and custom root CAs. It comes with ScreenCloud pre-installed, our SOC3 Type II certified digital signage app that encrypts data at rest and uses TLS for everything in transit. Uploaded content lives in Amazon S3, and access is restricted based on IAM permissions. At any time, you could request that your account data be deleted immediately.

If network downtime is an issue, caching ensures that most uploaded content will continue playing without interruption for up to 24 hours. Then, there are integrations for connecting to third-party apps and data. Content served by integrations usually isn’t stored on digital signage cloud servers (that’s the case for ScreenCloud, at least). But it’s still worth turning on audit logs and avoiding connecting your account to any platforms or services with PII. 

Tl;dr: Safely rolling out digital signage in schools requires media players with built-in security connected to segmented virtual networks and running software with zero access to sensitive data. With that setup, you could spin up anything from digital bulletin boards to livestreams of football games.

Digital signage content automation and delegation for schools

System admins have more important things to do than posting daily announcements and event updates. So, one of the first things you’ll want to do is create role-based access controls for a school secretary, student activities coordinator, or other staff in charge of communications. That would let you delegate content management with granular permissions based on a per-app or per-integration basis.

Adding a slide for a new teacher introduction or an event countdown timer to the school playlist is a breeze, even for someone who struggles with technology. You may even get to the point where there’s signage outside classroom doors. But no matter how experienced or well-intentioned users are, they’ll still ask for help at some point. The more updates you can automate, the better. 

The first place to start is with a digital signage app’s API. ScreenCloud, for example, lets you interact with your screens and your content using GraphQL mutations and webhooks. In the context of digital signage for schools, you could automate a million things, like calling someone to the office based on text in an email or a form response.

Interrupt pre-programmed playlists with quick campus-wide announcements

Apps and integrations like Noticeboard 2.0 make it a walk in the park to create basic text signs. But they still don’t make sense for a one-off announcement that you only need to display for five minutes. You still have to log in, type in the message, and add it to a playlist. With a GraphQL mutation and a webhook, someone in the principal’s office could send an email or fill out a form, and that text would show up on screens seconds later.

First, you’d want to create a page for displaying ad-hoc announcements. In ScreenCloud, you’d do that by logging into ScreenCloud, going to Apps, searching for Playgrounds, and creating a new instance. Select the blank template option and add some basic JavaScript and CSS (leave the HTML column as is) to display text from a webhook. Here’s an example:

JavaScript

const render = data => { var name = data.name; var location = data.location; ReactDOM.render( , document.getElementById("root") ) } getData().then(data => render(data));

CSS

#root {
    position: fixed;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    background-color: black;
}
#root h2, #root p {
    color: white;
    text-align: center;
}
#root h2 {
    font-size: 8.5em;
}
#root p {
    font-size: 5.5em; 
    margin-top: 10px; 
}

Then, click Application Data in the upper right corner of your Playgrounds window and update it to look something like this:

Click Preview in the upper right corner, and you should have a basic page for paging students or staff to a variable location. Return to the Application Data window and copy the API URL at the bottom of the screen. That URL will let you update the `name` and `location` values from a webhook. Make sure to click Save & Close before moving on to the next step.

If you manage the school website or intranet, you could create a basic HTML form with fields for the two values and run a PUT request on submission. You’d have to run the GraphQL mutation separately, though. With Zapier, you could handle everything in a single Zap.

To keep things simple in the Webhook step, you might grab the `name` value from the subject line and the `location` value from the email body, avoiding the need to parse out the two variables from a single source. In the Data field, you’d have "name": "{SUBJECT}", "location": "{BODY}". Add a Delay step of three seconds after sending the webhook data and before running the GraphQL mutation.

Before setting up the API call in Zapier, you need the screenIds for all the screens you want to interrupt and the appInstanceId of your announcement. You could use Postman to query all the Ids associated with your account (read our walkthrough for more details) or grab them from your ScreenCloud dashboard.

For your ScreenID, go to Screens, click on a screen, and copy the Screen ID below Device Information on the right side of the screen. For a Playgrounds appInstanceId, open an instance and copy everything that follows the final `/` in the URL. Now, you’re ready to run your GraphQL mutation in Zapier.

Add a Code step with Run JavaScript as the Event. Continue to the Action step and paste this into the Code textbox;

function getExpiresAt() {
	const now = new Date();
	return new Date(now.getTime() + 5 * 60 * 1000).toISOString();
}
const query = `
	mutation CreateCastsByAppInstanceId($input: CreateCastsByAppInstanceIdInput!) {
    	createCastsByAppInstanceId(input: $input) {
        	clientMutationId
    	}
	}
`;
const variables = {
	input: {
    	screenIds: ["SCREEN_ID1", “SCREEN_ID2”], 
    	appInstanceId: "APPID",
    	expiresAt: getExpiresAt()
	}
};
fetch('https://graphql.us.screencloud.com/graphql', {
	method: 'POST',
	headers: {
    	'Content-Type': 'application/json',
    	'Authorization': 'Bearer YOURTOKEN',
	},
	body: JSON.stringify({
    	query,
    	variables,
	}),
})
.then(response => response.json())
.then(data => {
	const output = {data: data};
	callback(null, output);
})
.catch(error => callback(error));

Update the SCREEN_ID, APPID, and YOURTOKEN values and give it a test run. If everything works, anyone with the trigger email can interrupt the default signage with a message that will automatically time out after five minutes. 

On the off chance that the trigger email and instructions fall into a student prankster’s hands, you might create a quick killswitch mutation that you can trigger as soon as possible with a voice command on your phone. Or, if your student body is more behaved than that, you could let students send text to a Playgrounds page moderated by OpenAI’s API. Anything that you can code in JavaScript, you can put on signage.

Secure, easy-to-maintain digital signage for schools

Safely casting compliant content to a fleet of campus screens doesn’t have to be a security nightmare. Start by connecting a single screen in the main office and set up a dashboard with graphs updated in real-time. Watch for unexpected downtime and suspicious network traffic to make sure that there aren’t any surprises. 

After a few days, add a user from the admin staff and let them spend a week playing around with a connected Notion dashboard or Google Slides presentation. If your free 14-day trial expires and everything goes smoothly, expand your fleet to include more screens covering more ground. It might end up being one of the school’s safest, easiest IT projects to manage.