> ## Documentation Index > Fetch the complete documentation index at: https://docs.oasm.io/llms.txt > Use this file to discover all available pages before exploring further. # Group > Organize assets into named groups to scope discovery runs and automated workflows A **Group** (asset group) is a named collection of [assets](/asset) used to scope discovery runs and [workflows](/jobs) to a subset of your attack surface. Instead of scanning everything every time, you define groups that represent the parts of your infrastructure you want to target — then run discovery and workflows against exactly that scope. You can reach the module from the console sidebar by opening **Groups** (under the **Attack surface** section; route `/groups`). > [!NOTE] > > Groups are workspace-scoped and operate only on assets within the same workspace. *** ## Why use groups * **Targeted operations** — run discovery or workflows against a specific subset of assets instead of the whole inventory * **Scoped automation** — scheduled workflows run only against the assets in the group * **Operational segmentation** — mirror your environments (production, staging, development) or business units * **Reusable scope** — define the collection once, reuse it across manual runs and schedules A group acts as the bridge between "these assets belong together" and "run this discovery/workflow only here". *** ## Groups vs targets Groups and [targets](/target) are complementary — they are not alternatives: | | Target | Group | | - | - | - | | **Role** | Defines the discovery *scope* (domains, IPs, CIDRs) | Collects discovered *assets* for scoped runs | | **Populates** | The [asset inventory](/asset) via discovery | Reuses that inventory in named collections | | **Used by** | Discovery jobs | Discovery runs and [workflows](/jobs) | | **Example** | `example.com` → discovers assets | `production-hosts` → scope a scheduled workflow | A target is where discovery starts; a group is where you assemble the results for targeted operations. *** ## Groups table The Groups page lists all groups in the workspace: | Column | Description | | - | - | | **Name** | The group's name | | **Total Hosts** | Number of hosts/assets currently in the group | | **Last Run** | When the group was last executed (discovery or workflow) | | **Created Date** | When the group was created | Use the **Create** button to start a new group, or click a group name to open its detail page (`/groups/:id`). *** ## Create a group **1. Open the create form** On the Groups page, click **Create** to open the creation form (`/groups/create`). **2. Name the group** Enter a descriptive name that reflects its purpose, for example `production-hosts` or `staging-services`. **3. Create the group** Submit the form. The new group appears in the list with zero hosts and no runs yet. **4. Add assets** Open the group and add assets from your existing [asset inventory](/asset). Assets inside the group define the scope of every run against it. *** ## Manage group assets The assets inside a group define the scope of every run against it: **1. Open the group** From the Groups page, click the group name to open its detail page (`/groups/:id`). **2. Add assets** Add assets from your existing [asset inventory](/asset). Only assets that exist in the workspace can be added — groups operate on discovered assets, not raw inputs. **3. Review the scope** Check the **Total Hosts** counter to confirm the group contains exactly the intended scope before running anything. **4. Remove assets** Remove assets from the group when they no longer belong to its scope. Removal only affects the group membership — it never deletes the underlying asset. *** ## Run discovery against a group With a group in place, you can execute discovery scoped to its assets: 1. Open the group's detail page 2. Trigger a discovery run — either manually or through a scheduled run 3. Monitor the run's progress in the [Jobs](/jobs) module Each run is recorded as either a manual run (started by you) or a scheduled run (started automatically by a schedule). This distinction appears in the job registry, so you can tell at a glance whether a run was an explicit action or part of the automation schedule. *** ## Run workflows against a group Groups scope [workflows](/jobs) as well as discovery. This lets you bind automation to a group: define a workflow once, attach it to the group, and trigger it manually or on a schedule — always against exactly the group's assets. **1. Attach a workflow to the group** Associate a [workflow](/jobs) with the group. **2. Run it** Trigger the workflow scoped to the group — on demand, or through a scheduled run. The run executes against exactly the group's current assets. **3. Monitor the run** Track progress and results in the [Jobs](/jobs) module, where the run shows whether it was manual or scheduled. > [!NOTE] > > Use scheduled runs for recurring checks (daily or weekly) and manual runs when you change infrastructure and want immediate coverage. See [Jobs](/jobs) for run history and status. *** ## Common questions > **Can the same asset be in multiple groups?** > > Groups are independent collections of workspace assets. Design them with a clear purpose — for example one group per environment — so a run scoped to a group only affects that group's members, and there is no ambiguity about what a job covered. > **Does deleting a group delete the assets?** > > No. Deleting a group removes the group and its configuration only; the underlying [assets](/asset) remain in the inventory. A deleted group's workflows are no longer scoped to anything, so recreate the group if the scope is still needed. > **What should a group's name express?** > > The name should make the scope obvious from job history alone — for example `production-hosts`, `staging-services`, or `customer-a-edge`. A reviewer should understand what a run covered without opening the group. > **How do scheduled runs differ from manual runs?** > > Both execute the same discovery or workflow logic against the group's assets. The difference is the trigger: scheduled runs are started automatically by the schedule, manual runs are started by a user. The job registry records the trigger type for every run. *** ## Best practices * **Segment by environment** — create separate groups for production, staging, and development so scans and workflows never mix scopes * **Scope scheduled scans** — attach schedules to groups instead of scanning the entire inventory, reducing noise and load * **Keep names descriptive** — `production-hosts` is clearer than `group-1` when you review job history later * **Review Total Hosts** — watch for unexpected jumps in the **Total Hosts** column, which can signal new exposure added to the scope * **Reuse workflows** — bind a workflow to several groups when the same checks apply, rather than duplicating configuration *** ## Related pages > **[Targets](/target)** > > Define the discovery scope that populates assets before grouping them. > **[Assets](/asset)** > > The inventory that groups collect and scope. > **[Notifications](/notifications)** > > Get notified when group-scoped discovery and automation runs finish. > **[Jobs](/jobs)** > > Track manual and scheduled runs triggered for groups. *** > [!NOTE] > > Everything available in the console is also available through the API — see the API Reference tab. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.