# Improving Requester Name & Phone Validation in Order Entry

**URL:** <https://talk.openelis-global.org/t/improving-requester-name-phone-validation-in-order-entry/2050>\
**Category:** Community\
**Tags:** dev\
**Created:** [March 3, 2026, 5:03pm UTC](https://talk.openelis-global.org/t/improving-requester-name-phone-validation-in-order-entry/2050 "2026-03-03T17:03:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![priyanshu56](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/priyanshu56/32/1148_2.png) [@priyanshu56](https://talk.openelis-global.org/u/priyanshu56)\
**Post date:** [March 3, 2026, 5:03pm UTC](https://talk.openelis-global.org/t/improving-requester-name-phone-validation-in-order-entry/2050/1 "2026-03-03T17:03:04Z")

</div>

While working on improving the Order Entry form validation, I noticed that the existing validation logic for requester names and phone numbers was too basic. It only checked for required fields, but didn’t enforce:

Only alphabetical characters in names  
Proper phone number formatting  
Better inline error visibility

This led to inconsistent form behavior and poor user experience when incorrect data was entered.

* * *

### What This PR Does

I’ve created a pull request to enhance validation with **minimal and effective changes** , without introducing any new libraries.

**PR Link:** [https://github.com/DIGI-UW/OpenELIS-Global-2/pull/2990](https://github.com/DIGI-UW/OpenELIS-Global-2/pull/2990)

The improvements include:

#### Stricter Name Validation

- Ensures requester first and last names contain:

- Rejects numbers and special characters

#### Simplified Phone Validation

- Enforces a **10-digit phone number**

- Allows only digits

- Optional field, but validated strictly when provided

#### Better User Feedback

- Inline error messages show immediately after moving out of the field (onBlur)

- Only one clear validation message per field

* * *

### Why This Matters

This approach:  
Improves UX by preventing invalid data from being entered  
Reduces repeated logic by using optimized Yup validation  
Keeps backend validation unchanged  
Follows the existing code structure and design guidelines  
Isn’t too restrictive — still practical for real-world names