Every result table filters and sorts on any column, which is how a finished analysis gets turned into the several smaller lists you actually distribute.
Filtering
- Each column has its own filter in the header row. Filters combine, so department plus risk level plus role narrows on all three at once
- Filters apply to the export. Filter to a population, export, and you get exactly that population, which is the normal way to produce a per-owner list
- Clearing a filter restores the full result. Nothing is discarded by filtering
Sorting
Click a column header to sort, click again to reverse. Sorting is most useful on execution count and last-used date, where it separates access somebody genuinely relies on from access that has sat unused since it was granted.
Large results
Rows load incrementally and the detailed report is read from a memory-mapped file, so a multi-gigabyte result opens without waiting for the whole thing to be read. Two consequences worth knowing:
- Scrolling to a far-off row takes a moment the first time and is instant afterwards
- The row count updates as loading progresses, so a total that is still climbing is not a bug
Filter after, or scope before?
Filtering is a view; scoping changes what runs. Prefer scoping when you can, for three reasons: the analysis is faster, the exported reports are small enough to open, and the execution log records the scope, so the evidence states what was examined rather than what was later hidden.
Filter after the run when you want several views of one population, for example the same analysis split by department and handed to each department head. Rescope when the population itself is wrong.
One case where the distinction matters: excluding accepted risks. Filtering them out of the view leaves them in the report and the log. Setting Risk exclusions in the criteria leaves them out of the analysis, and the log records that they were excluded. For audit work the second is what you want. See Supplementary Data Files.