Skip to content
English
  • There are no suggestions because the search field is empty.

09.01 Navigating the UI

A working tour of SimpleRisk's interface — the permission-driven sidebar, the top navigation, the breadcrumb trail, and the conventions that recur across every page once you know what to look for.

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. On a narrower window the sidebar automatically drops to an icons-only rail to protect the content width, 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:

  • A hamburger button and the SimpleRisk wordmark on the left. The hamburger collapses the sidebar (see The left sidebar, below); the wordmark — shown as a compact logo mark on narrow screens — links back to your home dashboard.
  • 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.
  • A bell icon opens your notifications panel. When you have unread notifications, a red badge shows the count (or "99+" once you exceed 99). Notifications are organized into Unread, All, and Trash tabs. See Notifications and Email Preferences.
  • Your user menu, shown as a circular avatar with your initials (or a generic person icon when your account has no name set) — 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.
  • Vulnerabilities — appears when the Vulnerability Management Extra is active and you have the vm_vulnerabilities permission. Sub-items include Vulnerabilities, Configure.
  • Incidents — 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.).

The sidebar's overall collapse state — expanded, the icons-only rail, or hidden — is remembered in your browser and survives both a page reload and a new session on that browser. Which module's submenu is open, by contrast, follows the page you're on: the module containing your current page expands automatically.

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 — grid layouts of customizable widgets. The Home dashboard is where you land after logging in: a row of KPI tiles (open risks, unmitigated risks, control pass rate, active frameworks, and the like) sitting above a What's Next? panel that lists what's waiting on you — risks due for review, mitigations to plan, audits to initiate, plus first-run setup steps you haven't finished yet. Home is permission-adaptive, so it shows only the tiles and items your role can act on; a compliance-only user sees compliance numbers, not risk ones. Like every dashboard, it's yours to rearrange — drag widgets, add or remove them, or restore the default. The area dashboards — the Risk Management Dashboard, the Compliance Dashboard, the Governance Dashboard — follow the same widget model. 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.

  • Not knowing the hamburger cycles three states. The hamburger button (top-left, next to the wordmark) doesn't just toggle the sidebar on and off. Each click advances it: expanded → icons-only rail → hidden → expanded. In the rail state, hover or click an icon to open its submenu in a flyout, so you never lose a destination. Your choice sticks across reloads.

  • Not collapsing the sidebar for screen-constrained work. On laptops with smaller screens, the sidebar's full width can crowd dashboard widgets. Click the hamburger to drop it to the icons-only rail — or let it happen on its own, since below roughly 990px wide SimpleRisk collapses to the rail automatically.

  • 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.

Related