Policies and Group Management

[Cubert]

Why Policies Aren’t Applied at the Group Level

Applying policies at the group level would force all members of that group to inherit the same scheduling behavior, eliminating flexibility. By contrast, assigning policies to computers individually (or via location/client inheritance) means:

- A single group can contain machines with diverse reboot needs (e.g., daily vs. weekly vs. monthly schedules).

- Policies remain decoupled from group logic, allowing you to reuse the same group of machines across multiple policies.

- You're free to dynamically adjust individual policy triggers without impacting the group structure.

So instead of creating multiple groups for each unique policy need (which would multiply complexity), we can support a multitude of policies per group with cleaner logic and less duplication.

Why “Groups” Are Really “Dependency Groups”

These groups aren't meant to enforce scheduling—they're designed to manage execution order and inter-device dependencies. That's why:

- They’re used to coordinate reboot sequencing, not scheduling.

- Each machine's policy determines when a reboot is due; the group determines how it's executed in relation to its peers.

- You can have a group like “SQL Tier” or “Web Layer” where machines are staggered with delays, regardless of their individual reboot policies.

This approach makes reboot logic modular:

Policy controls intent → Group controls execution discipline

This design is what makes Reboot Manager scalable. One consistent, dependency-based group can elegantly manage dozens of machines, each adhering to its own cadence, but rebooting in the right sequence when the time comes.
Want me to help craft messaging around this for users or documentation? I’d be happy to translate it into a client-friendly explanation.