CAPA root cause analysis template custom fields not persisting to database

QMS Arena QMS (by PTC)
, , , , , , , ,
1

We’ve added custom fields to our CAPA root cause analysis template in Arena QMS 2023.1, but the data isn’t persisting to the database. Users fill out the custom fields (Failure Mode, Contributing Factors, 5-Why Analysis), submit the form, but when they reopen the CAPA record, those fields are blank.

I’ve verified the custom field definitions exist in the template configuration, and the form displays correctly. The issue is specifically with data persistence - nothing gets saved to the database.

Checking the database directly:

SELECT custom_field_1, custom_field_2, custom_field_3
FROM capa_root_cause
WHERE capa_id = 'CAPA-2025-0042';

All custom field columns return NULL even though users entered data. Standard CAPA fields (description, assigned to, due date) save perfectly. Only our custom root cause analysis fields have this persistence problem. Is there a specific configuration flag that enables custom field persistence?

2

I checked both suggestions. The database columns DO exist - I can see custom_field_1, custom_field_2, custom_field_3 in the capa_root_cause table schema. And in the template editor, all three custom fields have “Persist to Database” checked. So the configuration looks correct on both ends, but data still isn’t writing. What’s the connection between the template field definition and the actual database column mapping?

3

Also verify your form submission payload. Enable network debugging in your browser and watch the POST request when users submit the CAPA form. Check if the custom field values are actually included in the JSON payload. Sometimes the form fields aren’t properly bound to the submission handler, so the data never leaves the client side. Look for your custom field IDs in the request body.

4

Check if the custom field columns actually exist in the database table. Sometimes the template configuration is saved but the database schema update script doesn’t run. Connect to your database and run: DESC capa_root_cause; or SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=‘capa_root_cause’. If your custom field columns aren’t listed, the schema migration didn’t execute properly.

5

There’s a mapping configuration file that links template field IDs to database columns. Check /config/templates/field-mappings.xml for your CAPA template. Each custom field needs an explicit mapping entry that connects the template field ID to the database column name. If this mapping is missing or incorrect, Arena doesn’t know which database column to write to even though both the field definition and column exist.

6

When you created the custom fields, did you set the persistence flag in the field definition? In the template configuration editor, each custom field has a checkbox for “Persist to Database”. If that’s unchecked, the field displays in the UI but data only stays in memory and never writes to the database. Go to Admin > Templates > CAPA > Root Cause Analysis and edit each custom field definition to verify this setting.

7

This is a multi-layered configuration issue that requires addressing all four components of the custom field persistence chain:

1. Custom Field Persistence Flag You’ve confirmed this is enabled, but let’s verify the complete configuration. In Admin > Templates > CAPA > Root Cause Analysis, each custom field should have these settings:

  • Persist to Database: ✓ (checked)
  • Storage Type: Database (not Session or Memory)
  • Field Scope: Record-level (not Form-level)

If any field has Storage Type set to “Session” or “Memory”, it will display but never persist. Edit each field and explicitly set Storage Type to “Database”.

2. Database Column Mapping The columns exist, but verify the mapping configuration is correct. Navigate to Admin > System > Template Configuration > Field Mappings and locate your CAPA template. You should see entries like:

<field-mapping template="CAPA_ROOT_CAUSE">
  <field id="failure_mode" column="custom_field_1" type="VARCHAR"/>
  <field id="contributing_factors" column="custom_field_2" type="TEXT"/>
  <field id="five_why_analysis" column="custom_field_3" type="TEXT"/>
</field-mapping>

The field IDs must EXACTLY match the IDs in your template definition. Even a case mismatch (failureMode vs failure_mode) will break the mapping. Export your template definition and compare the field IDs character-by-character.

3. Form Submission Payload Validation Enable payload logging to diagnose client-side issues:

  • Admin > System > Logging > Form Submission
  • Set log level to DEBUG
  • Submit a test CAPA with custom fields populated
  • Check /logs/form-submission.log for the POST payload

Look for your custom field data in the JSON payload:

{
  "capa_id": "CAPA-2025-0042",
  "failure_mode": "Material defect",
  "contributing_factors": "Supplier quality issue",
  "five_why_analysis": "Why 1: Material failed..."
}

If the custom fields are missing from the payload, the form binding is broken. Check your form template’s data-binding attributes in the UI configuration.

4. Field Type Compatibility Verify that the Arena field type matches the database column type:

  • Text fields (short) → VARCHAR(255)
  • Text fields (long) → TEXT or CLOB
  • Number fields → INTEGER or DECIMAL
  • Date fields → DATETIME or TIMESTAMP

A type mismatch can cause silent failures where Arena attempts the write but the database rejects it. Check your database error logs for constraint violations:

SELECT log_time, error_message
FROM system_error_log
WHERE table_name = 'capa_root_cause'
AND error_type = 'DATA_TYPE_MISMATCH'
ORDER BY log_time DESC;

Complete Resolution Steps:

  1. Verify Storage Type = “Database” for all three custom fields in template definition
  2. Export field-mappings.xml and validate field IDs match template exactly
  3. Enable form submission logging and verify custom field data in POST payload
  4. Query database error logs for type mismatch or constraint violation errors
  5. If mapping is incorrect, update field-mappings.xml and restart the application server
  6. If payload is missing custom fields, check form template data-binding configuration
  7. Test with new CAPA record after corrections

The most likely culprit is either incorrect field ID mapping (step 2) or Storage Type set to Session instead of Database (step 1). After correcting the configuration, existing CAPA records won’t retroactively populate, but new submissions should persist correctly. You may need to re-enter data for existing CAPAs.