River Drill-Down ​

Select a bucket on a river or junction graph, such as a User bucket of 501,459 at level 2, and list the identities behind its count. The table opens in seconds and loads the whole bucket, even for the largest groups in your environment.

Requires role: Viewer Related: Streaming River Rendering and Exact Counts, At-Scale Reads, Graph Explorer, Critical Junctions, Select Fire

Overview ​

River and junction graphs group access into buckets. Each bucket shows a type and a count, such as "Computer 245,678" or "Service account 12". The count says how many. An investigation usually needs to know which ones. Select a bucket to open a table of the identities behind its count, with the same name, criticality, tier and domain columns you see elsewhere in the product.

The table opens the same way for a bucket of 12 and a bucket of 500,000. The first rows appear within a few seconds, and the table keeps loading until it holds the whole bucket. The count in the table's toolbar is the exact number on the bucket you selected.

GraphnAI works out a large bucket's members once, the first time anyone opens it, and then serves the table from that result. Opening the same bucket again is immediate, for you and for everyone else.

Prerequisites ​

  • Role: Viewer or higher. Some pages that host these graphs, such as Select Fire and Critical Junctions, need the Operator role to open. The table follows the role that got you to the graph.
  • A finished sync: At least one identity sync has finished, so the graph has data to count.
  • No setup: It works on every bucket of every river and junction graph. There's nothing to turn on.

How to Use It ​

  1. Open a page with a river or junction graph, such as the Dashboard, Graph Explorer with an identity in focus, Critical Junctions, Security Posture, Detection Alerts, Boundary Escape, or the Simulate step of Select Fire.
  2. Select a bucket.
  3. Read the members in the table below the graph.

The table has Name, Criticality, Tier and Domain columns. Every row in it has the bucket's type, so the Type column appears only in Select Fire, where one table can list several types. The toolbar shows:

  • the bucket's type and count, such as "501,459 reachable"
  • the number of critical and Tier 0 identities in the bucket, when there are any
  • the direction: Outbound, Inbound or Both directions
  • the level, such as "Level 2"

Select a row to open that identity in Graph Explorer. In Graph Explorer, the row refocuses the graph on it. In the Select Fire Simulate step, the row closes Select Fire first.

In Graph Explorer, each name also has a Find shortest path button. It switches to the detail view and draws the path between the identity in focus and that member. Path search needs the Operator role.

To close the table, select Close (the X) at the right of its toolbar. On most pages, selecting the same bucket again also closes it.

What the States Mean ​

The table is always in one of these states, and each one looks different, so you can always tell whether it's working.

Loading ​

After you select a bucket, the toolbar reads "Loading…" and the table shows placeholder rows until the first page arrives. For a bucket that someone has opened since the last change to the graph, this is the whole wait: a few seconds at most.

"Computing members…" ​

The first time anyone opens a large bucket, GraphnAI has to work out its members before it can show any rows. While it does, the toolbar reads Computing members… in place of the count, and the table shows placeholder rows.

This happens once per bucket. After that, the bucket serves its rows straight away, for everyone, until the graph changes. Most buckets take a few seconds or less. A bucket of about 500,000 members takes about 30 seconds. The work runs in the background and never blocks the rest of the page.

If you select the bucket again while it's computing, or a colleague opens it at the same time, no second computation starts. Everyone waits on the same one.

Loading the rest ​

Once rows arrive, the table keeps fetching until it holds every member. A line under the table counts the rows so far, such as "Loading members: 1,200 of 501,459 so far…". You don't need to scroll or page. The line goes away when the bucket is complete.

"Couldn't finish loading." ​

When a later page fails, for example after a network drop, the rows you have stay on screen. A banner above the table reads "Couldn't finish loading. Showing the 1,200 rows that loaded." Select Retry in the banner to carry on from where it stopped.

When the first page fails, before any row appears, the table reads Couldn't load this list and "Check your connection and try again."

A finished bucket with no members reads Nothing here.

Sorting and Disabled Accounts ​

A disabled account carries the disabled symbol on its icon. Hover over it to read "Account disabled. Paths through it stay closed until it's enabled again."

On the graph, a bucket of users, computers or service accounts is split into enabled and disabled buckets, so a table usually holds one or the other. Where a table holds both, disabled accounts sort below enabled ones whichever column you sort by. The accounts that can sign in come first.

While the table is loading, rows appear in the order they arrive. When the whole bucket has loaded, the table sorts it by Name. Select a column header to sort by that column. A sort always covers every member of the bucket.

Export downloads the members' name, type, criticality and tier.

Where This Applies ​

PageNotes
DashboardBuckets on a finding's blast radius and permission graphs
Graph ExplorerThe river view of an identity in focus
Critical JunctionsInbound and outbound buckets around a junction
Security PostureBuckets on a failing check's blast radius graph
Detection AlertsBuckets on an alert's graph
Boundary EscapeBuckets on an exposed identity's blast radius graph
Select Fire (Simulate step)Blast radius buckets, before you choose an execution mode

On the Identity Inventory graphs, selecting a bucket filters the inventory table to that bucket's members instead of opening a separate table.

How Long Members Stay Ready ​

A bucket's members stay ready for 1 hour after they're worked out. A sync that changes relationships replaces them sooner: a full sync, an Entra ID sync, or a delta sync that changed relationships. A delta sync that changed nothing leaves them in place.

Closing the table, or leaving the page, cancels only the page you were waiting on. A bucket's first computation keeps running in the background and finishes, so the next person doesn't wait for it again.

Troubleshooting ​

The toolbar reads "Computing members…" for a long time ​

  • Cause: Someone opened a large bucket for the first time since the graph last changed, and GraphnAI is working out its members.
  • Fix: Wait. A bucket of about 500,000 members takes about 30 seconds. If it runs much longer, or never finishes, close the table and select the bucket again. If that doesn't help, ask an administrator whether the last sync finished cleanly.

The table reads "Couldn't load this list" as soon as you select a bucket ​

  • Cause: The first page failed, usually because of a brief network or server problem.
  • Fix: Close the table and select the bucket again. If it fails every time on the same bucket, ask an administrator to check the server logs for that identity.

"Couldn't finish loading." appears partway through ​

  • Cause: A later page failed after some rows had loaded.
  • Fix: Select Retry in the banner. It fetches the missing pages and keeps the rows you have. If the graph changed while you were loading, Retry starts again from the first page. The rows on screen stay valid while you wait.

The row count under the table is lower than the count in the toolbar ​

  • Cause: The table is still loading. The toolbar shows the bucket's exact count, and the line under the table counts the rows so far.
  • Fix: Wait for the line to go away. The table then holds every member.

A bucket opened earlier reads "Computing members…" again ​

  • Cause: Its members expired after 1 hour, or a sync changed relationships since. See How Long Members Stay Ready. The next person to open it waits for the one-time computation again.
  • Fix: Wait for it to finish. A delta sync that changed nothing doesn't cause this.

A table closed mid-load still seems to be working ​

  • Cause: A bucket's first computation keeps running after you close its table, so the work isn't wasted. See How Long Members Stay Ready.
  • Fix: None needed. The bucket is ready sooner the next time anyone opens it.