One name change, four systems
An employee gets married and changes her last name. She emails HR with a scan of the certificate. A generalist updates Workday, then remembers payroll is in ADP and updates it there. Benefits is a third system. Her email address and directory name are IT’s, so that becomes a ticket. A month later her paycheck and her badge show different names, and nobody is sure which update was missed.
Most HR requests look like this. The decision is simple. The work is copying the same change into every system that holds a piece of the employee.
How requests run
Employees submit from an HR portal with a form for each request type. The form asks only what that type needs and pulls the rest from the HRIS, so a name change asks for the new name, the effective date and the document, nothing else.
The request then follows rules you set by type and region:
- Name and address changes go to an HR specialist to check the document, then update Workday, payroll and benefits, and open an IT task for the directory and email alias.
- Verification letters fill a template from HRIS data and go out once someone in HR approves the draft. Routine letters can skip approval entirely.
- Leave requests go to the manager and HR together, update the time system on approval, and set reminders for the return date.
- Accommodations go to a named specialist only, with documents restricted to the people on the case.
Every change written to a system is recorded against the request, with who approved it. When the paycheck and the badge disagree, the record shows which step ran and which didn’t.
What HR gets back
Fewer emails asking “did you get my request?”, because employees can see it. Fewer errors from retyping. And a queue that shows what’s open, by type and region, instead of a shared inbox nobody can measure.
Teams usually start with the three or four request types that generate the most email. Most go on to employee onboarding, which reuses the same HRIS connection, and fold HR into a broader employee self-service portal.