We recently modified custom field mappings in our work order management module to add additional tracking parameters for material lot numbers. After deploying the changes, work orders are no longer updating their status from ‘In Progress’ to ‘Complete’ when operators finish production runs.
The custom field mapping was added to capture supplier batch codes, and we validated the field structure in the configuration UI. However, the status update triggers seem to be blocked now. When checking the backend mapping validation logs, I see warnings about field type mismatches, but the custom fields are defined as strings which should be compatible.
Has anyone encountered status sync failures after modifying custom field mappings? I’m particularly concerned about whether the mapping validation is interfering with the standard status workflow triggers. This is blocking our production reporting and causing operators to manually update statuses.
I’ve seen this before. When you add custom fields to work order entities, you need to check if your status transition rules have dependencies on field validation. The mapping validation process can block status updates if any required fields fail validation checks, even if they’re not directly related to the status change.
Can you share the XML snippet of your custom field mapping configuration? Specifically the validation rules section.
Here’s the field mapping section from our configuration:
<CustomField name="SupplierBatchCode" type="String" maxLength="50"/>
<FieldMapping source="MaterialLot.BatchID" target="WorkOrder.SupplierBatchCode"/>
<ValidationRule field="SupplierBatchCode" required="false"/>
The field is marked as not required, so I’m confused why it would block status transitions. The warnings mention type mismatches but both source and target are strings.
I agree with Tom’s assessment. Additionally, check if your status transition workflow has any custom scripts or business rules that iterate through all work order fields for validation. Sometimes custom code will attempt to access all mapped fields, and if the MaterialLot.BatchID source isn’t populated for all work orders, it causes the script to fail silently. This is especially common in DAM 2021 where field mapping exceptions weren’t always properly logged in the standard workflow engine logs.
The issue is likely in how the status update trigger evaluates the work order object state. Even though your custom field is marked as not required, if the field mapping references a MaterialLot property that doesn’t exist or is null at the time of status update, it can cause the entire validation chain to fail. The backend mapping validation is probably throwing exceptions that aren’t being surfaced properly in the UI. Check your application logs for NullPointerException or mapping resolution errors during status transitions.
Another thing to verify - does your work order completion trigger fire before or after material lot association? If the status update happens before the material lot is linked to the work order, the field mapping will try to resolve MaterialLot.BatchID on a null reference. You might need to reorder your workflow steps or add a null check condition to the field mapping rule. The validation warnings you’re seeing are probably related to this timing issue rather than actual type mismatches.
We had this exact scenario last quarter. The root cause was that the custom field mapping validation was interfering with the status update trigger execution order. Here’s the complete solution that addresses all three aspects - custom field mapping, status update triggers, and backend mapping validation:
1. Custom Field Mapping Fix:
Modify your field mapping to include a null-safe evaluation. Update your configuration:
<FieldMapping source="MaterialLot.BatchID" target="WorkOrder.SupplierBatchCode">
<NullHandling>SKIP</NullHandling>
</FieldMapping>
This tells the mapping engine to skip the field update if the source is null rather than failing validation.
2. Status Update Triggers:
The status transition rules need to be decoupled from custom field validation. In your work order workflow configuration, add a pre-condition check:
<StatusTransition from="InProgress" to="Complete">
<PreCondition>WorkOrder.StandardFields.AllValid</PreCondition>
<PostAction>WorkOrder.CustomFields.UpdateIfAvailable</PostAction>
</StatusTransition>
This ensures status updates aren’t blocked by custom field mapping issues. The custom fields update after the status transition completes.
3. Backend Mapping Validation:
Enable detailed mapping validation logging to catch these issues earlier. Add to your system configuration:
com.delmia.apriso.mapping.validation.level=DEBUG
com.delmia.apriso.workflow.status.failOnMappingError=false
The second property is crucial - it prevents mapping errors from blocking status transitions while still logging them for review.
Additional Steps:
- Clear your workflow cache after making these changes
- Test with a single work order first to verify status updates work
- Review the mapping validation logs to ensure the NullHandling directive is being applied
- Consider adding a scheduled job to populate missing SupplierBatchCode values for existing work orders
The key insight is that DAM 2021’s validation framework treats all field mappings as atomic operations by default. By explicitly configuring null handling and separating custom field updates from status transitions, you maintain data integrity while allowing workflows to complete successfully. This approach has worked reliably across multiple implementations where custom fields are added to core entities.