What is available
Enrolled screens... an invite link and an authenticator code. The audience is the screens you chose.
Available on MAX with the Campus add-on, included at ALPHA.
The problem this solves
Ask any multi-site venue what actually goes wrong and it is rarely the video. It is that somebody at the far end has to make it work each time.
Log in before the service. Find the right link. Remember which account. Get someone on the phone when it does not work. And that somebody is at the site with fewer volunteers than your main building, twenty minutes before people arrive.
A distribution system that needs a technical person present every week has not solved distribution. It has created a second staffing requirement somewhere less able to carry one.
What enrolment changes
The screen is registered once. An invite link, an authenticator code, done.
Afterwards it is recognised. Switch it on and it reconnects by itself... no login, no link to find, nobody who needs to know anything.
The far site's job becomes: turn on the screen.
That is the entire operational requirement, and it is what makes multi-site sustainable for volunteer teams rather than being a thing that works while one particular person keeps turning up.
And it is a real access control
The second half, which matters for a different reason.
A link alone is a link anyone can forward. Enrolment means the receiving screens are the ones you enrolled... not whoever happens to have the address.
For a service being sent to a second building, that is the correct model. You are not broadcasting to the public; you are sending to specific screens in specific rooms. The system should reflect that rather than relying on the link staying private.
Who benefits
Multi-site venues, obviously.
Church plants in rented rooms, where the person opening up is not the person who understands AV.
Anyone with a screen in a room they do not visit often... an overflow space used monthly, a hall used for occasional events.
Venues whose second site keeps failing for non-technical reasons. If the pattern is "it works when Sarah is there", the problem is not the network.
What still needs a person
Being straight about the remaining requirements:
Someone turns it on. Screens do not switch themselves on.
Someone should know what to do if it stays dark. Who to call, whether to wait, what happens if it does not come back. Not because failure is likely... because a room of people needs someone with an answer.
The connection at the far end still matters. Enrolment removes the login; it does not improve the network. A site on mobile data may need Relay.
Practical notes
Enrol during setup, not before a service. Do it on a quiet afternoon at the far site, then test it cold the following week.
Test the cold start. Switch the screen off entirely, leave it, switch it on. That is the real test... not whether it works while you are standing there having just configured it.
Keep the codes somewhere findable. If the person who enrolled the screens leaves, someone needs to be able to enrol a replacement.
Re-enrol when hardware changes. A new screen is a new screen.
Why it matters more than it sounds
The features that make multi-site possible are the video ones. The features that make it last are these.
A venue can get a second site working with almost anything, once, with the right person present. Keeping it working every week, for years, when that person is on holiday... that is a different problem, and it is solved by removing the requirement for anyone to do anything.
Available now on MAX with the Campus add-on.