Building Custom Fields in a GRC Platform — Challenges and Solutions

One thing I underestimated when I first started building my GRC platform was the amount of flexibility people want when it comes to metadata. Everyone asks for “just a couple of extra fields,” and before you know it, you’re knee-deep in requirements around conditional logic, multi-model support, imports, exports, surveys, reporting, and tenant isolation.

Custom fields seem simple until you actually start designing them for a multi-tenant GRC environment. That’s when the fun begins.

Here are the real challenges I hit, and the approach that finally worked.

---

1. Every Model Wants Custom Fields… But Not the Same Ones

Libraries want different fields than Records.
Records want different fields than Requirements.
And then there are “types” inside each of those.

In a GRC system, this isn’t optional. Controls, Policies, Standards, Risks — each one comes with its own metadata patterns. Trying to shove everything into a single fixed schema would be a disaster.

Solution:
I built a central “field definitions” table that stores:

• which model a field belongs to (record, library, etc.)
• whether it applies to all types or only specific ones
• field type (text, dropdown, number, boolean…)
• validation rules
• grouping, sort order, visibility

Each model that supports custom fields has a simple custom_fields JSON column. Definitions describe the schema, and the JSON column stores the actual values.

Simple inside the model, flexible outside the model.

---

2. Conditional Logic Is a Rabbit Hole

“If you select X, show these three other fields.”
“If you select Y, now this field becomes mandatory.”

These requests sound small in the moment, but they change your entire architecture if you try to hack them in UI-only.

Solution:
I moved the logic into the definitions themselves:

• controller_key (which field controls this one)
• operator (is_true, equals, in, etc.)
• condition_value
• visible_when_matched
• required_when_visible

This way, the UI, backend validation, imports, and exports all follow the same rules. No special-case code. No spaghetti JS. The rules live in one place.

---

3. Reporting and Integrations Need Predictable Data

GRC tools almost always end up in Tableau, PowerBI, or some internal reporting engine. Custom fields make reporting messy:

• different tenants define different fields,
• different record types have different schemas,
• fields appear/disappear over time.

Solution:
Hybrid approach:

1. Store values in JSON per record (fast, flexible, easy to evolve).
2. For reporting, flatten the fields you care about into a dedicated reporting table or materialized view.

Your transactional system stays clean, and your BI tools get tidy columns.

---

4. Import/Export Needs to Respect Custom Fields Too

If you allow tenants to import Records, Requirements, or Controls, they expect custom fields to work just like native fields.

Without planning, this becomes a nightmare:

• you don’t know which tenant has which fields
• you don’t know which types apply
• you can’t validate consistently

Solution:
During import, I load all definitions for that model + type, then parse columns by field_key. Validation rules come straight from the definition. On export, I include active fields automatically.

No hardcoding, no guesswork.

---

5. Tenancy Complicates Everything

Some tenants want global fields.
Some want tenant-specific fields.
Some want to override defaults.

If you don’t plan for it early, it becomes unpatchable.

Solution:
Every field definition supports:

• tenant_id = null → global/shared field
• tenant_id = X → tenant-specific override or extension

When querying, I return:

• all global definitions
• plus all tenant-specific ones
• filtered by model + type

Works cleanly without endless if-else checks.

---

6. User Experience Matters More Than the Data Model

Admins need a UI where they can create fields without thinking about the backend structure. If the UI feels clunky, nobody uses the feature, and all the engineering work goes to waste.

Solution:
I built a simple UI that lets admins:

• select a model and (optionally) a type
• add fields with labels, keys, groups, required settings
• define dropdown options
• configure conditional visibility
• order fields
• activate/deactivate fields

Then a generic “Custom Fields” tab on each form renders everything dynamically.

---

7. The Big Lesson

Custom fields in a GRC platform aren’t “extra metadata.”
They are the product.

GRC content is unpredictable, diverse, and constantly evolving. The only way to stay sane is to treat custom fields as a core architectural feature, not an afterthought.

The hybrid JSON + definition-driven schema turned out to be the sweet spot:

• flexible enough for any tenant
• simple enough to maintain
• powerful enough to support surveys, onboarding forms, evidence requests, vendor questionnaires, etc.
• structured enough for reporting

If you’re building a GRC system from scratch, bake this in early. Retro-fitting it later is ten times harder.