Groups
Organise endpoints into logical groups, apply policies at scale, and keep your workspace tidy.
Overview
Groups are the fundamental organising unit in Xcellerate RMM. Instead of managing endpoints one by one, you place them into groups and apply policies (patch schedules, monitoring rules, automation scripts) at the group level. When you change a policy, every endpoint in that group picks up the change automatically.
Groups can represent anything: a client, a site, a device type, or a business unit. You can also nest groups to mirror complex organisational structures (e.g. Acme Corp → London office → Servers).
Key concepts
- Static group — endpoints are added or removed manually.
- Dynamic group — membership is determined by a filter rule (e.g. "OS = Windows 11 AND department = Finance"). Endpoints enter or leave automatically when their attributes change.
- Group policy — the set of patch, monitoring, and automation rules attached to a group. Policies cascade: a child group inherits its parent's policy unless overridden.
- Default group — every tenant has one. Newly enrolled endpoints land here until you move them.
Step-by-step walkthrough
Create a group
Navigate to Groups → New group. Enter a name, an optional description, and choose a parent group (or leave at root). Click Create.
Choose static or dynamic
On the group detail page, open the Membership tab. For a static group, drag endpoints from the sidebar or use the Add endpoints button. For a dynamic group, click Set filter rule and build your criteria.
Assign a policy
Open the Policy tab. You can start with the default policy and customise individual settings, or create a brand-new policy from scratch.
Review and save
Verify the endpoint list and policy summary, then click Save. Changes propagate to agents within one polling cycle (default: 5 minutes).
Tips & best practices
- Start with broad groups (e.g. per client) and refine as your endpoint count grows.
- Use dynamic groups for OS-based segmentation — they update themselves when machines are upgraded.
- Avoid deeply nested hierarchies (more than 3–4 levels) — they make policy inheritance harder to reason about.
- Name groups consistently: consider a pattern like
[Client] – [Site] – [Role].