Security Models and Branch Types

Naming note: the Settings card is titled "{Branch} Types" (using your organization's custom label — see What is custom labeling?), but the screen you land on is headed "Child Organization Security Models." These are two names for the same underlying thing, seen from two angles.

Four related concepts, easy to conflate:

1. Security Model — a reusable policy template: which apps a child organization created under it can use (and whether any are force-enabled), age/content compliance rules, an identity-provider requirement, and default security-role rights. This is the container.
2. Branch Type — a named, enable/disable-able label attached to a Security Model (e.g. "Franchise Location"). A model can carry more than one Branch Type.
3. Creating a sub-organization — happens on a different screen entirely (Network → Create), not here. When creating one, a member picks a Branch Type from the available list — that's the actual moment a Security Model gets applied to a real organization.
4. Master Model — a separate, singular record governing the top-level organization's own capabilities when no parent has assigned it a branch type. It has the same structure minus Branch Types themselves (a master model doesn't need any — there's nothing above it to pick from).

Why this matters for Apps & Features

The per-app availability a Security Model sets (Optional-default-on, Optional-default-off, Not Available, or Force-Enabled) is exactly what drives the padlocks and forced toggles you'll see on the Apps & Features screen for any organization created under that model — see What Controls Which Apps You Can Turn On