After upgrading from Aras 12.0 to 13.0, our quality team is encountering validation errors when trying to submit nonconformance reports. We have several custom required fields on the Nonconformance form (Root Cause Category, Corrective Action Priority, Cost Impact), and users are getting “Required field missing” errors even when all fields appear to be filled out.
The error specifically says: “The property ‘root_cause_category’ is required but has no value.” When I inspect the form, the dropdown shows a selected value, but the validation is still failing. This is blocking our quality reporting process.
Here’s the property definition for one of the failing fields:
The validation worked fine in Aras 12.0. I suspect the upgrade changed something with how form validation handles custom required fields or default values. Has anyone else experienced validation issues with custom fields after upgrading to Aras 13.0?
I’ve solved the validation issue after thorough investigation. The problem was indeed related to changes in Aras 13.0’s form validation handling, specifically around required field visibility and default value initialization. Here’s the complete solution:
Root Causes Identified:
Form Field Visibility Timing: Aras 13.0 changed when form validation executes relative to field visibility rules. Our custom required fields had visibility conditions based on the Nonconformance Type field, and validation was running before visibility rules completed.
Default Value Initialization: Required list properties without explicit default values now fail validation during form initialization, even before users interact with the form.
List Entry Configuration: Some of our list definitions had an empty entry at position 0 that appeared as a blank option in dropdowns. Selecting this blank entry (or having it auto-selected) counted as “no value” for validation purposes.
Solution Steps:
Fix 1: Add Default Values to Required Properties
<Item type="Property" action="edit">
<name>root_cause_category</name>
<is_required>1</is_required>
<data_type>list</data_type>
<default_value>To Be Determined</default_value>
</Item>
Added appropriate default values for all custom required fields:
root_cause_category: “To Be Determined”
corrective_action_priority: “Medium”
cost_impact: “Under Review”
Fix 2: Update List Definitions
Removed empty first entries from all related lists
Ensured each list has a valid default entry
For lists where “not applicable” is valid, created explicit “N/A” entries rather than using empty strings
Administration > Lists > [List Name] > Values tab
Fix 3: Modify Form Field Visibility Rules
Updated the Nonconformance form to handle visibility more explicitly:
Moved visibility conditions from property level to form field level
Added form initialization script to set field visibility before validation runs
Used onFormPopulated event to ensure fields are properly visible/hidden before first validation
Form initialization code pattern:
// Ensure required fields are visible and have values before validation
var ncType = item.getProperty('nonconformance_type');
if (ncType === 'Material' || ncType === 'Process') {
// Show and initialize root cause fields
form.setFieldVisibility('root_cause_category', true);
if (!item.getProperty('root_cause_category')) {
item.setProperty('root_cause_category', 'To Be Determined');
}
}
Fix 4: Update Form Field Required Attribute Configuration
Opened Nonconformance form in Form Designer
For each custom required field, verified “Required” checkbox matches property definition
Ensured field binding (propertyName) exactly matches property name
Set “Required Message” to provide clear user feedback
Fix 5: Configure Conditional Required Logic
For fields that should only be required under certain conditions:
Used form events to dynamically set required state rather than relying on property-level settings
Implemented validation logic that checks conditions before enforcing required state
Added clear visual indicators (red asterisks) that update based on form state
Verification Testing:
Created new Nonconformance records - no validation errors
Tested all Nonconformance Type variations to verify conditional field behavior
Verified existing nonconformance records can still be edited and saved
Tested with different user roles to ensure permissions weren’t affecting validation
Confirmed list dropdowns show valid default selections
Additional Configuration for Smooth Operation:
User Communication: Documented the new default values and explained that “To Be Determined” entries should be updated during the investigation phase
Workflow Updates: Modified Nonconformance workflow to include validation gates that check if default “placeholder” values have been updated to actual root cause data
Report Filters: Updated quality reports to exclude or flag records still using default placeholder values
Key Lessons from Aras 13.0 Upgrade:
Required fields MUST have default values if they have any visibility conditions
Form validation timing changed - test all custom forms thoroughly after upgrade
List properties need valid first entries, not empty strings
Client-side form scripts may need updates for compatibility with new form framework
Test conditional field visibility extensively with the new validation engine
After implementing these fixes, form validation works correctly and our quality team can submit nonconformance reports without errors. The key was addressing both the property-level configuration (default values) and the form-level behavior (visibility timing and initialization).
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if your custom fields have default values set in the property definition. Aras 13.0 introduced stricter validation rules for required fields. If a field is required but doesn’t have a default value, and the form doesn’t explicitly set a value before the first validation check, it can fail even if the user sees a value in the UI. The timing of when validation runs versus when field values are committed changed slightly in 13.0.
This is a known issue with form field visibility rules after upgrades. In Aras 13.0, the form rendering engine changed how it handles field visibility and editability states. If your custom fields have conditional visibility rules (show/hide based on other field values), the validation might be checking the field before the visibility rules execute. Try temporarily removing any visibility conditions to see if the validation passes, which would confirm this is the issue.
Look at the form field binding. After an upgrade, sometimes the field bindings get reset or the property names don’t match exactly between the form definition and the ItemType property definition. Open the form in Form Designer, select your custom field, and verify the ‘propertyName’ attribute matches exactly (case-sensitive) with the property name on the Nonconformance ItemType.
Confirmed this resolves the form validation timing issue in Aras 13.0 — adjusting the required field visibility conditions before validation execution eliminated the nonconformance custom field errors immediately.
Check if there are any client-side validation scripts that were added to your Nonconformance form. Custom validation JavaScript might not be compatible with Aras 13.0’s updated form framework. The validation error could be coming from custom code rather than the standard Aras validation. Review any onFormPopulated or onBeforeUpdate events attached to your form.
I had a similar issue after upgrading. The problem was that list properties without a default value or with an empty string as the first list entry were failing validation. Aras 13.0 is stricter about null vs empty string for list fields. Make sure your list definitions don’t have an empty first entry that users might be inadvertently selecting.