Groups and Policies

A group is a set of assets inside one environment. A policy is the configuration that forwarders receive: which file types to collect, which paths to skip, how hard to work, and when to scan. You attach one policy to a group, and every asset in that group receives it. Groups and policies are how you make a collection decision once for two hundred machines instead of two hundred times.

Every environment has a Default Policy, applied to all of its assets. Anything you add on top of that is a policy on a group, and an asset can be in more than one group at a time.

What is the difference between a group and a policy?

A group answers "which machines". A policy answers "what do they do".

They are separate because the two questions change on different schedules. The set of developer machines changes weekly as people join and leave; what you want collected from a developer machine changes once a year. Keeping them separate means the weekly change is a membership edit and not a policy rewrite.

Both are scoped to a single environment. A group cannot span environments and a policy cannot be shared between them, so an organization with several environments configures each one.

How do policies stack?

The default policy is applied first, then every policy from every group the asset belongs to is merged onto it. Merging is not "last one wins": each setting has its own rule, and the rules are not all in the same direction. This is the part of the system that produces surprises, so here it is in full.

Setting	How two policies combine
Extension list	Union. The asset collects every file type either policy enables
Exclusions	Union. The asset honors every exclusion from either policy
Scan mode	Backscan-only wins. If either policy sets only-backscan mode, the asset gets only-backscan mode
Backscan schedule	Earliest start wins. The end time and jitter come from that same winning policy
CPU limit, network limit	Smallest non-zero value. Zero means unlimited, so an unlimited policy never loosens a limited one
Process priority	Lowest priority wins
Sightings rate limits	Smallest non-zero value for each field
Start new installations in sleep mode	Most restrictive wins. Sleep beats active

Read down that table and one pattern emerges: adding a group to an asset makes it collect more file types and fewer paths, under tighter resource limits. The two exceptions to "more restrictive wins" are the extension list and the exclusion set, and both of them are unions, so both move in the same direction as each other even though that direction is opposite for the two settings.

The practical consequences:

You cannot loosen a restriction by adding a group. If a machine is hitting a CPU limit you did not intend, the fix is to find which of its groups sets it, not to add a group with a higher one.
You cannot un-exclude a path by adding a group. An exclusion anywhere in an asset's group set applies to it.
You can add file types by adding a group. This is the intended way to collect an extra format from a cohort without touching the default policy.
Overlapping backscan windows resolve to the earliest. If one group says start at 02:00 and another says start at 22:00, the asset starts at 22:00 and uses that policy's end time. Check this when a machine is scanning at a time you did not schedule.

What is in a policy?

A policy editor has three tabs.

Tab	What it controls
Extensions	The file types the forwarder collects. Two default categories, Executables and Binary Code and Scripts and Bytecode, plus a Custom category for formats you add
Forwarder settings	Scan mode and schedule, sightings rate limits, installation defaults, and the advanced resource controls
Exclusions	The environment-level exclusions attached to this policy

The extension categories that ship with Stairwell can be turned on and off per extension but not deleted, which is deliberate: an extension you disable is recorded as disabled rather than removed, so the list stays legible and reversible. Anything you add goes in Custom.

Everything under Forwarder settings is covered in detail in Asset Configuration. Exclusions are covered in Exclusions.

How should I structure groups?

Start with the default policy doing the work, and add groups only where a cohort genuinely needs something different. Three group shapes cover almost everything:

A cohort with a performance problem. Developer machines, build servers, container hosts. This group carries the exclusions and the resource limits that would be wrong for the fleet. A dynamic group on a hostname pattern or OS keeps it current on its own.
A cohort with a scheduling constraint. Machines that must not scan during business hours get a group with only-backscan mode and a window.
A staged rollout cohort. A group you use to push a forwarder upgrade to a small set of machines first. See Update the Forwarders in a Group.

What to avoid is a group per machine, and a policy per group when the policies are identical. Both make the stacking table above much harder to reason about when something is unexpectedly restricted.

Where do I find them?

In Settings, under Environments:

Asset policies, to create and edit policies.
Asset groups, to create groups and manage membership.
Asset exclusions, to create the exclusions you attach to a policy.
Asset registration, to have newly registered assets land in a static group automatically, so they get its policy on their first check-in rather than after you notice them.

Each of those lists is filtered by environment with the chip at the top, so confirm you are in the right environment before you create anything.

What should I read next?

Manage Groups, for static versus dynamic groups and how to fill them.
Create and Edit Policies, for the create and edit procedures and a field reference.
Asset Configuration, for what every forwarder setting does and its default.