09.01 Navigating the UI

Why this matters

Most of SimpleRisk's UI conventions are stable across pages — once you understand the sidebar logic, the breadcrumb trail, and the permission-driven menu visibility, the rest of the application is navigable. New users who haven't internalized the conventions waste time hunting for menus that don't appear (because their role doesn't grant the relevant permission) or wondering why the same feature has slightly different surface depending on which path they took. The fifteen minutes spent learning the navigation pays back across every subsequent session.

The other reason this matters: SimpleRisk's interface is permission-filtered everywhere. The sidebar shows only the menus your role grants, the report library shows only the reports your permissions allow, the form fields show only the actions your gating permissions support. This means two users on the same instance can have substantially different experiences of the same UI; documentation that describes "the sidebar" assumes a maximally-permissioned view that not every user will see. When something looks missing, the first question is "do I have the permission for it?" rather than "is the feature broken?"

The third thing worth knowing: SimpleRisk's UI doesn't ship a light/dark theme toggle in Core. The visual style is fixed (a single skin5 theme class hardcoded in the rendering path). There's no per-user theme preference, no admin-configurable color scheme, no high-contrast mode. Programs needing alternate themes either build them via custom CSS overrides or live with the default appearance.

Before you start

Have these in hand:

Login credentials for a SimpleRisk user account.
A read on which permissions your role grants. Different roles see different sidebar menus; the menus you see reflect what your role allows. If your role is one of the seeded ones (Risk Submitter, Risk Reviewer, Compliance Manager, Admin), you'll see the menus appropriate to it. (See Permission Reference in the Administrator Guide.)
A browser with reasonable screen real estate. SimpleRisk's UI is designed for desktop screens; tablet and mobile work but the sidebar collapses to a hamburger menu and some dashboard widgets get cramped.

Step-by-step

1. The top navigation bar

After login, the top of the page shows a horizontal navigation bar containing:

The SimpleRisk logo or product name on the left, linking back to the dashboard or home page.
The page breadcrumb showing the current page's path (e.g., Risk Management → Submit Risk).
Action icons on the right side, depending on activated Extras:
The AI chat icon (if the AI Extra is active and configured) — opens the AI Assistant chat panel on the right side of the screen. See Working with SimpleRisk AI.
User account dropdown — links to your profile, password change, and logout.

The breadcrumb is useful for orientation in deeply-nested pages. Click any breadcrumb segment to jump back to that level.

2. The left sidebar

The sidebar is the primary navigation surface. It shows a list of top-level modules, each of which expands to reveal its sub-items. Which top-level modules appear depends on your account's permissions:

Risk Management — appears when you have the riskmanagement permission. Sub-items include Submit Risk, Perform Reviews, Plan Mitigation, Prioritize Planning, Review Regularly, plus the Risk Management Dashboard tile in Reporting.
Compliance — appears when you have the compliance permission. Sub-items include Define Tests, Active Audits, Past Audits, plus framework management surfaces.
Governance — appears when you have the governance permission. Sub-items include Frameworks, Controls, Documentation, Document Exceptions.
Asset Management — appears when you have the asset permission. Sub-items include Manage Assets, Manage Asset Groups.
Vulnerability Management — appears when the Vulnerability Management Extra is active and you have the vm_vulnerabilities permission. Sub-items include Vulnerabilities, Configure.
Incident Management — appears when the Incident Management Extra is active and you have the im_incidents permission. Sub-items follow the NIST 800-61 phases (Preparation, Identification, Response, Lessons Learned, Closed).
Assessments — appears when the Assessments Extra is active and you have the assessments permission. Sub-items include Assessment Contacts, Questionnaire Templates, Questionnaires, Questionnaire Results, Risk Analysis, Import/Export, Questionnaire Audit Trail.
Reporting — appears for users with any of riskmanagement, compliance, governance, or asset permissions. Includes the Reports Hub, the dashboards, and the report library.
Configure — appears for users with admin permissions. Contains the system configuration surfaces (Settings, Permissions, Extras, etc.).

Each top-level module's expand-collapse state persists across page loads but doesn't persist across sessions (refresh the browser and it's back to default).

The order of modules in the sidebar is fixed — there's no per-user sidebar customization in Core. Programs that need custom sidebar ordering can override via custom CSS, but the default order is what most users will see.

3. The page content area

Each page renders below the breadcrumb in the main content area. Common page patterns:

Datatable pages (the lists — Risk Management's risk list, Manage Assets, Document Exceptions, etc.) — show a sortable/filterable table with per-row actions. Most datatables support column customization (which columns to show, in what order); see Favorites and Personalization.
Detail view pages (a single risk, a single incident, a single document) — usually tabbed, with each tab showing a different aspect of the entity.
Form pages (Submit Risk, Add Document, etc.) — multi-section forms, often with required and optional field groups.
Dashboard pages (the Risk Management Dashboard, the Compliance Dashboard, the Governance Dashboard) — grid layouts of customizable widgets. See The Risk Dashboard and The Compliance Dashboard.

4. Common UI conventions

Several patterns recur across SimpleRisk's pages:

Save buttons land at the bottom right of forms. Forms with multiple save modes (Save vs. Save & Send) put both buttons together.
Tabs are clickable headers at the top of the content area. Clicking a tab swaps the content below; the tab order matches the workflow order (e.g., Risk Details → Scoring → Mitigation → Review).
Required fields are marked with a red asterisk or equivalent visual indicator.
Tooltips appear on hover for fields whose meaning isn't obvious from the label.
Confirmation dialogs appear before destructive actions (delete, close, deactivate) — read them before clicking through.
Audit-trail sections at the bottom of detail views show the change history for the current entity. Useful for "what happened to this risk in the last week?"

5. Browser conventions that work

A few things browser-side make navigation faster:

Bookmark frequently-used pages. SimpleRisk's URLs are stable; bookmarking /management/index.php (Submit Risk), /management/review_risks.php (Review Regularly), or your favorite report saves the multi-click path each time.
Use the browser's back button. SimpleRisk's pages mostly behave well with browser navigation; the back button takes you to the previous page state in most cases (the exception: forms with unsaved changes will prompt before discarding).
Open detail views in new tabs. When working through a list of risks, ctrl-click (or cmd-click on Mac) to open each risk in a new tab — keeps the list page available for the next click.
Refresh after long-running operations. Some operations (bulk imports, large data syncs from Extras) update data behind the page's view. If something looks stale, refresh.

6. Logging out and session management

The user account dropdown in the top-right offers Logout. SimpleRisk sessions don't auto-logout aggressively (the session timeout is admin-configurable), but for shared workstations, an explicit logout is the safe pattern.

For users with active edits in a form, logout will lose unsaved changes — save first.

Common pitfalls

A handful of patterns recur with navigation.

Looking for menus that aren't visible. The sidebar is permission-filtered. If you can't find the Risk Management menu, you don't have the riskmanagement permission. The fix is administrative (ask your admin to add the permission to your role), not navigational. Don't waste time hunting for hidden menus.
Treating breadcrumbs as authoritative for the current location. Breadcrumbs are based on the URL path, not on how you got to the page. Two routes to the same destination produce the same breadcrumb. For "where am I in the workflow," the active sidebar entry is more reliable than the breadcrumb.
Closing tabs with unsaved form data. Browsers warn before navigating away from forms with unsaved changes (when the form supports the warning). They don't always warn before tab close. Save explicitly when working in long forms; don't rely on the warning.
Expecting a global search bar. Core SimpleRisk doesn't ship one. Per-page table filters are the search surface for most lists. The Advanced Search Extra adds a topbar search box if installed (see Search for the candid story).
Navigating with browser back during multi-step forms. A multi-step form submitted partway through and then back-buttoned to the previous step may lose state. The forms aren't all SPA-style; some retain state, some don't. Use the form's own navigation (Save & Continue, Previous, etc.) when the form provides it.
Treating the sidebar's expand state as persistent. The sidebar expand/collapse persists during a session but resets on browser refresh. If you collapse a menu to reduce visual clutter, you'll need to re-collapse after a refresh.
Not collapsing the sidebar for screen-constrained work. On laptops with smaller screens, the sidebar's full width can crowd dashboard widgets. The hamburger icon (where present in your theme) collapses the sidebar to icons-only mode, freeing horizontal real estate.
Trying to bookmark filter state. Some pages encode filters in URL query parameters (the Compliance Dashboard's ?frameworks=id1,id2,... is one example) and bookmark cleanly. Others store filter state server-side and don't reflect it in the URL — bookmarking those pages produces a default-state bookmark, not the filtered view you saw. For filter-state bookmarking, look for query parameters in the URL bar; their absence means the bookmark won't capture the filter.