If you've set up a custom validation on a default field and you’re getting a validation-type error while entering data into that field, even though the data you're entering matches the validation you've set up, the field may have built-in (hardcoded) restrictions in addition to your custom validation.
Why the validation works in settings but fails in the employee profile:
- Some out-of-the-box fields in Bob come with predefined format restrictions. Even if you rename the field, those original restrictions still apply.
- For example, the default “Social insurance number (SIN)” field includes built-in format rules. If this field is renamed and a custom validation is added, the system will still enforce the original restriction in the backend.
Although the system allows you to configure a custom validation pattern, the built-in validation remains active in the background. That means:
- The custom validation does not override the original system validation
- Both validations must be met at the same time
If the two validations contradict each other, no value will pass — even if it matches your custom pattern
This explains why testing the pattern inside the validation settings works (it checks only the custom rule), but saving the value in an employee profile fails (it checks both the custom rule and the built-in restriction).
You can review the field in the Employee fields report to confirm whether it’s a renamed system field rather than a newly created custom field.
If the built-in validation conflicts with your required format, the recommended workaround is:
1. Rename the existing field (to clearly mark it as the original system field).
2. Export the current data from this field via a report or the People directory as a backup.
3. Archive the original field.
4. Create a new custom field in the relevant category.
5. Apply your desired custom validation pattern to the new field.
6. Re-enter or bulk import the data into the new field.
The new custom field will only enforce the validation you define, without any hidden restrictions.
Key takeaway:
Custom validations and built-in field validations work together — they don’t override one another. If you’re using a renamed out-of-the-box field, hidden restrictions may still apply and cause unexpected validation errors.
When your required format differs from the original field logic, creating a new custom field is the cleanest solution.