05.04 Managing Dropdown Values

Why this matters

Every dropdown on the risk submission and mitigation forms (Category, Source, Technology, Location, Risk Status, Planning Strategy, Mitigation Effort, Close Reason, and dozens more) is backed by a lookup table you can edit. The defaults are reasonable starting points, but the language a program actually uses ("Asset Class" instead of "Technology," "Avoid / Transfer / Mitigate / Accept" perhaps with an additional "Outsource" your program adds) is rarely the exact default. Tailoring these dropdowns produces forms that feel native to your organization and reports that read in your terminology rather than the application's.

The honest scope to know up front: dropdown management is a Core feature, not Customization-Extra-gated. The Add and Remove Values admin page (simplerisk/admin/add_remove_values.php) covers most of the lookup tables; a few specialized pages handle others. You don't need to activate any Extra to manage dropdown values; activation is only required for the more substantial customization layers (Custom Fields, Custom Risk Scoring, form-layout changes — see the rest of this chapter).

The other thing worth knowing: dropdown changes affect existing data in different ways depending on the relationship type. SimpleRisk uses two patterns:

By-ID relationships (the dominant pattern): existing risks store the dropdown's id or value field, not the display name. Renaming a value changes the display everywhere — old records suddenly show the new name; the relationship is preserved.
By-name relationships (rare, mostly historical): some legacy fields store the display name as a string. Renaming the lookup value leaves existing records pointing at the old string, which doesn't match anything.

The vast majority are by-ID. The ones to watch for are noted below.

The third thing: deleting a value used by existing records produces orphaned references. The records keep their stored id; the lookup id no longer matches anything; the display shows blank, "Unknown," or the literal ID depending on the rendering path. Deleting is a one-way operation; reassign before deleting.

Before you start

Have these in hand:

Admin access to Configure → Add and Remove Values (the centralized dropdown-management page) and to the few specialized pages (e.g., Configure → Custom Names for impact and likelihood labels, Configure → Risk Catalog for catalog entries).
A list of the dropdown changes you want to make. A typical program edits 5–15 dropdown values at initial customization; doing them in a single session is more efficient than one-at-a-time as needs surface.
A backup if the install has been live for a while. Dropdown changes don't usually corrupt data, but a botched bulk-rename followed by a regret is easier to recover from with a backup than by remembering every change.

Step-by-step

1. Identify which lookup table you want to edit

The lookups grouped by which dropdown they back:

Risk identification (Details tab):

category — the Risk Category dropdown.
source — the Risk Source dropdown.
location — the Location dropdown.
technology — the Technology / Asset Class dropdown.
team — the Team multi-select (managed via Configure → Teams; see Team-Based Segregation).

Risk lifecycle:

status — risk status values used internally.
close_reason — the reasons offered when a risk is closed.
regulation — regulatory frameworks the risk maps to.
risk_grouping — high-level risk groupings (used in the risk catalog).
family — risk family classifications (also used in the catalog).

Mitigation:

planning_strategy — Mitigate, Transfer, Avoid, Accept, etc.
mitigation_effort — Low, Medium, High, etc.
mitigation_cost — cost categorization for mitigation.
mitigation_controls — control maturity / control mapping for mitigation.

Review:

review — review verdict values (Consider for Mitigation, Approve, etc.).
next_step — the next-step labels presented during review.

Threats and assets:

threat_grouping — high-level threat groupings.
threat_catalog (managed via the Risk Catalog page) — the threat catalog.
asset_groups — asset groupings (with the Asset Management Extra).

Compliance:

test_status, audit_status, audit_phase, test_frequency — compliance test and audit lookups.

The list isn't exhaustive; the Add and Remove Values admin page typically lists every lookup it manages, so the page itself is the canonical inventory for your version.

2. Open the management page for the lookup

Sidebar: Configure → Add and Remove Values. The page presents a dropdown to select the lookup table, then displays the current values with Add, Update Name, and Delete controls.

For specialized lookups (impact and likelihood labels, risk-level names, etc.) the management surface is a different page; see the Custom Names admin page or the appropriate specific page (the navigation typically labels them clearly).

3. Add a new value

Pick the lookup table from the dropdown.
Type the new value in the Add a New Name input.
Click Add.
The page refreshes; the new value appears at the bottom of the list.

The new value gets a generated id (or value field, depending on the table). It's immediately available in any dropdown that draws from this lookup.

4. Rename an existing value

Pick the lookup table.
Find the value to rename.
Click Update Name (or the equivalent control).
Enter the new name; save.

The rename updates the lookup row's name field; the underlying id doesn't change. Every existing record that referenced the value by ID now displays the new name. This is the right behavior for almost every rename use case.

5. Delete a value

Before deleting, confirm no records reference the value:

For risk-related lookups, check the risk register — search or filter on the value to see how many risks use it.
If any records use it, decide whether to reassign them to a different value first or accept that they'll become orphaned.

Then:

Find the value in the management page.
Click Delete.
Confirm.

The lookup row is removed. Records that referenced the value by ID retain their stored ID; the dropdown displays blank or "Unknown" for those records depending on the rendering path. To clean up:

Open each affected record and reassign to a different (still-existing) value.
Or accept the orphans and trust the empty display.

For lookups where deletion isn't safe (the lookup is referenced by integrity-critical foreign keys or the application has a hard requirement on the value), the management page may refuse the delete; the error message should indicate why.

6. Reorder values (where supported)

Some lookups support drag-to-reorder, controlling display order in the dropdown. Where supported:

Drag the value to its new position.
The order saves automatically.

Reordering is purely cosmetic; no relationships change. Use it to put the most-common values at the top of dropdowns where users will pick them most often.

7. Verify changes

After bulk dropdown edits, walk through the affected forms:

Open the risk submission form; confirm the dropdowns show your new values in the right order.
Open an existing risk; confirm renamed values display correctly.
Open the relevant reports; confirm the new values appear where expected.

If anything's off, the dropdown management page is the place to fix it.

8. Communicate dropdown-value changes

Dropdown values appear in user-facing forms, in reports, in dashboards, and in audit-trail entries. A user who's been picking "Mitigate" for years and now sees only "Implement" needs to know that's the same concept. Communicate any rename:

A short announcement explaining the change and the old → new mapping.
Updated screenshots in your program documentation.
Updated training materials for new submitters.

For the program's external stakeholders (auditors, regulators, executives) who see SimpleRisk-rendered reports, mention the terminology change in the next round of report distribution.

Common pitfalls

A handful of patterns recur with dropdown management.

Deleting a value used by many records. Orphans the records. Either reassign first or accept the orphans explicitly. Don't pretend "I'll fix the orphans later" — that "later" rarely comes.
Renaming values without updating training materials. New users get confused; old users keep using the old name in conversations; the rename creates a translation tax. Update materials proactively.
Adding many similar values that should have been one. "Risk Category: Operational, Operational - HR, Operational - Finance, Operational - IT" — the four categories should probably have been "Operational" with a separate sub-category dropdown. Categorization design matters; avoid creating value-explosion through over-specific naming.
Treating dropdown management as a substitute for proper data modeling. A dropdown of "Owning Customer Names" with 200 entries should be an Asset link to a Customer entity, not a dropdown. Use dropdowns for short, slow-changing categorical data; for high-cardinality or relational data, model it properly.
Reordering values mid-program for no good reason. Users notice; muscle memory breaks. Reorder when there's a real reason (a new most-common value justifies promotion to the top); otherwise leave the order alone.
Confusing dropdowns managed by Add and Remove Values with dropdowns managed elsewhere. Some specialized values (impact and likelihood labels, risk-level names, custom-fields options) are managed via different admin pages. If you can't find a value on the Add and Remove Values page, look in the specialized pages.
Deleting a value used by an integration as a key. An integration that submits risks with category = "Application Security" keeps trying to submit with that string. If you delete or rename it, the integration submits and fails (or creates risks with empty category). Coordinate dropdown changes with integration owners.
Letting the dropdowns drift into stale values. Programs that ran for years often accumulate dropdown values that aren't used anymore. Periodic cleanup ("which categories haven't been used in the last year?") keeps the dropdowns useful. This is a reasonable annual hygiene task.
Adding values without a naming convention. "Operational risk" / "Operational Risk" / "operational risk" all become separate dropdown values with different IDs. Pick a casing convention and stick to it.
Forgetting that team and user lookups are managed differently. Teams are managed via Configure → Teams; users via Configure → User Management. The Add and Remove Values page doesn't manage either.

Reference

Permission required: check_admin for the Add and Remove Values admin page and the related lookup-management pages.
API endpoint(s): Lookup tables are exposed via various /api/v2/admin/... endpoints (e.g., GET /api/v2/admin/categories, POST /api/v2/admin/categories); the exact set depends on the lookup.
Implementing files: simplerisk/admin/add_remove_values.php (the centralized management page); simplerisk/admin/custom_names.php (impact, likelihood, and similar specialized lookups); simplerisk/includes/functions.php (add_name($table, $name, $size=20) ~line 7075; update_table($table, $name, $value, $length) ~line 6419; delete_value($table, $value), delete_value_by_id()).
Database tables: Many — category, source, location, technology, status, close_reason, regulation, risk_grouping, family, planning_strategy, mitigation_effort, mitigation_cost, mitigation_controls, review, next_step, threat_grouping, test_status, audit_status, audit_phase, test_frequency, etc. Each lookup typically has columns value (id) and name.
config_settings keys: None directly; lookups are table-driven, not setting-driven.
External dependencies: None.