Every policy type in a collaboration platform works the same way: one global default applies to everyone, named policies override it for the people you assign, and assignment happens either directly on a user or through a group. Direct assignment is fine for fifty people and unmanageable for five thousand. Group assignment is the mechanism that lets policy follow the organisation chart instead of a spreadsheet.
The Model in Four Lines
- The global policy is the floor: everyone inherits it unless something else is assigned.
- Named policies carry alternative settings for specific populations.
- Direct assignment pins a named policy to one user.
- Group assignment pins a named policy to a security group; membership changes then update policy automatically.
Precedence: When Several Claims Collide
A user can be covered by a direct assignment and by three groups at once. The resolution order is consistent: direct assignment wins over any group; among groups, an explicit rank decides, with lower rank numbers winning. Two habits prevent surprises: keep ranks documented in one place, and reserve direct assignment for genuine exceptions — every direct pin silently defeats future group changes for that user.
Changes are not instant
Group-based policy assignment propagates on a delay — often hours, occasionally longer for large groups. Plan rollouts accordingly: assign the pilot group today, verify tomorrow, and never debug a "policy did not apply" ticket five minutes after clicking save.
Designing the Groups Themselves
Policy groups should mirror durable organisational populations, not projects: "finance-staff", "contact-centre-agents", "executive-assistants". Reuse existing HR-driven groups where possible — they are already maintained by joiner-mover-leaver processes, which means your policies inherit that maintenance for free. A policy group that someone must remember to update is a policy group that will be wrong during an audit.
A Rollout Pattern That Works
- Create the named policy; leave the global default untouched.
- Assign it to a pilot group of twenty or thirty representative users, including at least one complainer — they find the edge cases.
- Run for one full work week; collect friction through a dedicated channel rather than email.
- Adjust, then swap the pilot group for the production group in one change, keeping the pilot group assigned for a further week as canaries.
- Only after stability, consider folding the setting into the global default and deleting the named policy — fewer policies means fewer precedence puzzles.
Documenting What You Did
For each named policy keep four lines of record: which population, which difference from global, who approved it, and when it should be reviewed. Policies accumulate like furniture; the review date is what stops the console from becoming an archaeological site where nobody dares delete anything.
Group assignment handles who gets which rules. The next chapter moves one level up: the rules about creating the team spaces themselves — naming, ownership and approval flows that prevent sprawl before it starts.
