New hires from HR to payroll without retyping
When HR hires someone, payroll, finance and IT each need to know. How to send new hires from an HR system such as NEOGOV to the ERP and to IT's request queue, with personal data handled carefully.
A new hire is a single event that touches several offices. HR finishes onboarding in its system. Payroll needs an employee record. Finance may need the person set up as a payee for reimbursements. IT needs to create accounts and order equipment before the first day.
In many cities, each office gets the news by email and types it into its own system. The result is predictable: misspelled names, wrong departments, and new staff who start without a login.
Map the handoffs first
Before automating, write down who needs what, and by when.
| Office | Needs | By when |
|---|---|---|
| Payroll | Employee record: name, position, department, start date, pay details | Before the first payroll |
| Finance / AP | Payee vendor for reimbursements | Before the first expense claim |
| IT | Accounts, email, equipment | Before the first day |
| Department | Desk, keys, training | Before the first day |
Each row is a possible flow. Start with the one that causes the most pain.
A typical flow
- On a schedule, each morning. Read yesterday's hires from the HR system.
- Map fields. Name, position, department and start date into the ERP's shape.
- Translate codes. HR's department and position codes into the ERP's codes, with a value map.
- Create the employee. A record in the ERP for payroll.
- Create the payee vendor. So reimbursements can be paid.
A second branch can open a request in IT's service desk, so account setup starts without anyone forwarding an email.
Code tables are the hard part
HR systems and ERPs almost never use the same department or position codes. A value map, a small table that says "HR code X means ERP code Y", handles this.
What matters most is what happens when a code isn't in the map. The flow shouldn't guess. It should hold that hire back and tell someone, so a person adds the missing code and the next run catches up.
Handle personal data carefully
New hire records carry some of the most sensitive data a city holds: Social Security numbers, birth dates, home addresses and bank details.
- Send only what each office needs. IT needs a name, department, title and start date, not an SSN.
- Mask or remove sensitive fields before they go anywhere that doesn't need them.
- Keep them out of emails and alerts. Exception emails should name the hire by ID or name only.
- Make sure nothing keeps a copy along the way: no staging tables, no logs with full records.
Bank details for direct deposit are often best entered directly in payroll by the employee or payroll staff, rather than moved by an integration at all. Decide this with payroll and HR.
Timing and corrections
- Run daily, not instantly. HR often corrects a record soon after the hire. A morning run picks up the corrected version.
- Look back a few days. If a run fails, the next one should still find the hire.
- Don't create duplicates. Check whether the employee already exists before creating one.
- Changes after creation. Decide whether later HR changes, such as a new title, should update the ERP too, or stay manual for now.
Test with made-up people
Never test with copies of real employees. Create a few made-up hires covering the main cases: a normal hire, a missing department code, a rehire of a former employee. Run them against a test ERP environment if you have one.
The connectors
HR and ERP APIs are usually licensed per agency, and the details can sit behind each vendor's customer portal. Ask both vendors early for API access, an integration user and documentation. That request is often the longest step in the project.
In SentraBridge
A SentraBridge template sends new hires from NEOGOV to Munis as an employee and a payee vendor, with value maps for codes and a Protect fields step to mask or remove sensitive fields. Both connectors are built from public documentation and confirmed with your own accounts during setup. Records pass through in memory and aren't stored. See rules and value maps.