Structuring Your Groups

Not sure where to start with Groups? This guide walks through how to think about your structure, with concrete examples you can copy and adapt.

Static or Dynamic: Which Do You Need?

Start every group with this question: can you describe who belongs using an employee attribute?

• If yes, an attribute like job title, department, location, manager, or role, use a Dynamic group. Electric will keep it current for you.

• If no, it's a hand-picked list that doesn't map to any attribute (a special project team, a leadership group, a pilot cohort), use a Static group.

A good rule of thumb: if you'd have to think about who to add or remove every time someone joins or changes roles, that's a sign the group probably has an attribute behind it, and should be Dynamic instead.

A Starter Structure

If you're building from scratch, this shape works for most organizations:

All Employees (parent group) Universal apps everyone needs: email, chat, password manager.

Department groups (children of All Employees) Department-specific tools, inheriting the universal apps automatically.

• Engineering, Job title contains "Engineer" or "Developer"

• Sales, Job title contains "Sales" or "Account Executive"

• Finance, Job title contains "Finance" or "Accounting"

Location or entity groups (children of All Employees, or their own top-level groups) Location-specific tools: VPN configs, region-specific compliance training, local benefits portals.

• US Employees, Country is United States

• Canada Employees, Country is Canada

Role-based groups (cut across departments) Groups based on responsibility rather than department.

• Managers, Job title contains "Manager" or "Lead"

• Admins, Role is Admin

Exception groups (Static) For anyone who doesn't fit a clean rule, executive assistants with cross-department access, a contractor with a one-off tool, a pilot group testing a new app.

How Hierarchy and Inheritance Work

Groups can have a parent group. This does two things:

• Application inheritance. A child group automatically inherits the applications attached to its parent, on top of whatever it has of its own. This is why "All Employees" as a top-level parent works well: put your universal apps there once, and every department or location group underneath it gets them automatically.

• Scoped membership for Dynamic child groups. If a Dynamic group has a parent, its rules only run against employees who are already members of that parent, not your whole organization. So a "US Managers" group that's a child of "US Employees" only ever checks for managers within that US group, it can't accidentally pull in a manager based elsewhere.

You're not locked into the hierarchy you start with. Groups can be reparented, moving a group to sit under a different parent, later on as your structure evolves, rather than needing to rebuild it from scratch.

Pro Tip: Build your hierarchy top-down. Start with the broadest group ("All Employees"), then add departments and locations as children, rather than building specific groups first and trying to retrofit a parent underneath them later.

Rule Examples to Copy

Combine conditions with Add AND rule when someone needs to match more than one thing at once (like "Job title contains Manager AND Country is United States" for US-based managers only), and use Add OR rule group when there's more than one way to qualify (like the Engineering example above).

Before You Build a New Group, Ask

1. What applications or actions depend on this? If nothing is actually attached to the group, you probably don't need it yet.

2. Is there a shared attribute behind this list? If yes, build it as Dynamic. If it's truly one-off, Static is simpler and won't need upkeep.

3. Does a broader group already cover this? Check whether an existing parent group could just inherit down, instead of duplicating applications across two separate groups.

4. Will this group still make sense in six months? Groups built around a specific person ("Sarah's team") age poorly. Groups built around a role or attribute ("Sales") don't.

Common Pitfalls

• Too many one-off Static groups. If you're manually managing five different lists that all boil down to "people in Sales," that's a sign that one Dynamic group would save you the upkeep.

• Rules that are too broad or too narrow. "Job title contains Manager" will also catch "Account Manager" if that's not a people-manager role at your company, consider whether that's intended.

• Forgetting to attach applications. A group with no applications attached does nothing, it's just a label. Always double check the Applications tab after building a group.

For the full walkthrough on creating and managing groups, see the main Groups article.