SkieCan head office set rules that branches cannot override?
Yes. Settings can be locked at a higher level, so a branch, a school admin or a teacher cannot change them. Head office keeps the safety baseline fixed, and branches adjust only what they are allowed to. Blocking also beats allowing, so a blocked app cannot be switched back on lower down.
A chain of schools usually wants two things that pull against each other: one safe baseline everywhere, and enough freedom for each campus to run its own classes. Skie handles this through the structure. Rules attach at the organisation level and flow down. Each level below can add its own policy and app list, and the most specific level applies last.
Locking is what gives head office the final word. A locked setting is fixed for everything beneath it, so a branch head cannot turn off a hardening switch, change the web filter or relax the Chrome rules. Fixed items might include blocking uninstall, factory reset, VPN apps and alternative browsers, along with the school-wide filter.
Blocking beats allowing. If head office blocks an app, no branch list can allow it. A branch can still tailor lists for its own groups within what is left, and can request new apps through the approval flow.
The effective policy view shows what a given device really ends up with once every level is combined, and where each setting came from. That answers the common branch question of why something is blocked. Role scoping also means branch heads do not see settings outside their own branch.
General-purpose tools such as Hexnode and Scalefusion are built for many kinds of business. Skie is built around schools, so the levels carry school names: organisation, school, branch and group.
A practical tip: lock only what you would never want changed, and leave everything else open. Over-locking creates support tickets.