Organizational Units

Organizational units (OUs) scope your JupiterOne data to the teams that own it. An OU groups the assets, controls, and findings that belong to a single part of your organization so that each team can see its own posture without asking a central team to build a report. OUs are used as a filter in both Compliance (Continuous Control Monitoring) and Vulnerability Management, and are configured once from a single admin interface.

Namespaces and organizational units

OUs are organized into namespaces. A namespace is a grouping dimension — a way of dividing your environment — and the OUs inside it are the individual buckets along that dimension.

JupiterOne provides one built-in namespace and lets you create as many custom namespaces as you need:

• Integration (built-in) — A system-managed namespace where every integration instance in your account is automatically an OU. This namespace is read only: you cannot edit or delete it or its queries. Its OUs follow the integration instance lifecycle — when you add an integration its OU appears, and when you remove an integration its OU is removed.
• Custom namespaces — Namespaces you define yourself, where OU membership is computed from J1QL queries. Use custom namespaces to group your environment by team, business unit, region, environment, tag, or any other dimension that matters to your organization.

A single entity can belong to OUs in more than one namespace at the same time. For example, an EC2 instance can be in the Production OU of an Environment namespace and the Platform OU of a Teams namespace simultaneously.

The organizational unit admin interface

Configure namespaces and OUs from a single page. Navigate to Settings > Organizational Units to open the OU admin page.

The page lists every namespace as an expandable grouping. Expand a namespace to see the OUs it contains in a table with:

• OU name and integration icon — the name of the bucket, with the provider icon shown for integration-derived OUs.
• Assets — how many entities are scoped to this OU.
• Metadata — an Added or Missing badge indicating whether the OU has an owner configured. OUs without an owner are flagged Missing so you can see at a glance what still needs attention.

Create a custom namespace

1. On the OU admin page, click New namespace.
2. Enter a Name (for example, Teams) and an optional Description.
3. Optionally select a Default workflow — the default ticketing workflow used to route unassigned-case tickets for OUs in this namespace.
4. Add one or more Queries that define how entities are bucketed into OUs.
5. Click Save namespace.

Each query must RETURN exactly two aliased columns:

• AS entityId — the matching entity.
• AS ouValue — the bucket key the entity is grouped by (a region, a tag, a team name). This value becomes the OU's label.

The bucket value must be populated on every matching entity. When you project an optional property such as a tag or a custom field, filter to entities that have it with WITH, otherwise the save fails with "must return at least one of ouValue or ouId".

warning

Always project the bucket key AS ouValue. A second alias, AS ouId, is accepted only for keys that are UUIDs, but OUs created this way have no human-readable label and show as raw identifiers in the filter and admin interface. Use AS ouValue for every namespace query.

For example, to group AWS accounts by their Team tag:

FIND aws_account WITH tag.Team != undefined AS a
RETURN a._id AS entityId, a.tag.Team AS ouValue

A namespace can contain several queries — each one contributes its matched entities to the OUs in that namespace.

tip

Start broad. A namespace that buckets every asset by a single tag or owner attribute you already maintain (for example, tag.Team or tag.Environment) gives every team a self-service view with almost no setup.

Configure OU routing metadata

Click any OU in the table to open its detail panel and configure routing metadata — who owns the OU and where its work is routed:

• Owner email (primary owner) — The primary person responsible for the OU. This is required for the OU to count as configured, and it receives the OU contact digest.
• Additional owner emails — Secondary owners, entered as a comma-separated list.
• Ticket workflow — The ticketing workflow used to route cases for this OU.

Changes persist immediately and are available through the API.

tip

Set a primary owner email on every OU. The owner email clears the Missing badge, drives the OU contact digest, and identifies who to route a finding or control failure to when it belongs to that team.

Filtering by organizational unit

Once your namespaces and OUs exist, you can filter by OU in both Compliance and Vulnerability Management. The OU filter narrows every view to the assets, controls, and findings that belong to the selected team.

In Compliance (Continuous Control Monitoring)

The Controls Status View and its drill-down can be scoped to one or more OUs.

1. Open the Org Units filter at the top of the Controls Status View.
2. Select one or more OUs, organized by namespace.
3. The controls list filters to show only the controls with results related to assets in the selected OUs.
4. The summary header adapts to show OU-specific compliance metrics, and the drill-down shows which assets within the selected OUs are affected, with individual pass and fail status.

The OU selection persists in the URL, so you can share a link to a specific OU's compliance view with a team member.

tip

Give each team lead a self-service compliance view. An IT or Cloud Ops leader can select their OU and immediately see their team's compliance posture without asking the central compliance team for a report.

In Vulnerability Management

In Vulnerability Management, the OU identifies which team owns an affected asset and drives where remediation work is routed.

• The Owner team column shows the OU that owns the affected asset on the Prioritized view and on remediation plans.
• Filtering by OU narrows the vulnerability funnel to the findings on assets owned by that team.
• When you create a remediation plan, the OU determines which team the resulting case is routed to.

Vulnerability Management draws owner teams from a single configurable namespace, set as the OU namespace in the Risk configuration panel. It defaults to the built-in Integration namespace, so change it to a custom namespace — such as a team or business-unit grouping — when you want cases routed by that dimension instead.

Organizational unit metadata on entities

OUs are represented on the graph through internal metadata, which is what makes OU filtering and scoping possible. All internal metadata uses an underscore (_) prefix.

Every entity carries an _ou property: a pipe-delimited set of <namespace-slug>:<value> tokens for every OU the entity belongs to, across all namespaces. For example, an entity might carry |integration:8f3c…|teams:platform|environment:production|. The built-in Integration namespace populates these tokens automatically; custom namespaces populate them by evaluating their queries.

Property	Type	Description
_ou	string	The set of OUs the entity belongs to, as pipe-delimited namespace:value tokens. This is what the OU filter matches on.
_integrationInstanceId	string	Internal UUID of the integration instance the entity was ingested from. Backs the built-in Integration namespace.
_integrationName	string	User-provided friendly name of the integration instance. Surfaced as the OU name in the Integration namespace.
_integrationType	string	Type of the integration, typically the provider name (for example, aws, azure, okta).

You can filter entities by OU in J1QL using the _ou property and the ~= contains operator. For example, to find every entity in the platform OU of the teams namespace:

FIND * WITH _ou ~= '|teams:platform|'

note

For the built-in Integration namespace, _ou tokens are assigned and maintained by JupiterOne and follow the integration instance an entity was ingested from. For custom namespaces, membership is recomputed from the namespace queries — edit the query to change which entities fall into which OU.

For the full list of internal metadata assigned to entities and relationships, see Entity and Relationship Metadata.

Related topics

• Continuous Control Monitoring
• Vulnerability Management
• Entity and Relationship Metadata