Does a promotion need to go through the same approval process as a separation?

Not really, even though both start as a request to change an employee's status. A promotion typically needs a department head and HR to sign off. A separation needs those same approvals plus steps a promotion doesn't, like revoking system access. Treating every personnel action as identical either slows down the simple ones or lets a complex one skip a step it actually needed.

What happens if one approver in the chain is out of the office?

In a paper or email-based process, the request usually just waits, since the next person can't act on something they don't have yet. A process where every approver can see the request and its current status as soon as it's submitted doesn't depend on one person's inbox to keep moving. The delay, if there is one, is at least visible instead of invisible.

Why does a new hire need a different approval path than a pay adjustment?

A new hire typically triggers steps a pay adjustment doesn't, most commonly IT provisioning and building or system access, in addition to the usual HR and payroll sign-off. Routing every action through the same generic path means either the new hire's provisioning steps get bolted on manually, or a pay adjustment gets held up waiting on approvals it was never going to need. Once that hire is approved, a separate question follows: getting the actual onboarding paperwork to every office that needs it.

Who defines which approval path each type of action follows, and what happens when that needs to change?

The organization does, without having to build anything itself. The paths are set up around how approval authority is already assigned: which actions a department head signs off on alone, which need HR review, which touch payroll. When that changes, a new approver, a restructured department, an action type that didn't exist last year, the routing changes with it. The paths should describe how the organization works today, not how it worked when the form was first designed.

How do you keep employee data accurate when it has to be entered into multiple systems?

The biggest source of error is usually re-entry: someone retyping the same information from a completed form into a second or third system, a step where transcription mistakes are easy to make and hard to catch. Capturing the data once, with validation at the point of entry, removes that re-entry step rather than trying to catch the errors it produces after the fact.

What does an auditor or a records request actually need to see for a personnel action?

Generally, who initiated the request, who approved it and when, and what specifically changed at each step, not just the final outcome. A record that only shows the end result, the new title or the new pay rate, doesn't answer those questions on its own; the approval sequence itself has to be part of what's kept.

Why a promotion, a transfer, and a separation shouldn't all follow the same approval path

Flow Forms · HR and personnel operations

The short answer

A personnel action request is the internal approval process for any official change to an employee's status: a new hire starting, a promotion, a transfer, a pay or grade change, or a separation. Each of these is a genuinely different kind of request, needing a different set of approvals and triggering different downstream steps, not one generic path applied the same way regardless of type. Routed through one generic approval chain anyway, either every request waits on steps it doesn't need, or a request that does need a specific step, like provisioning a new employee's system access or revoking it after a separation, moves through without anyone catching that the step was skipped. Doing it well means the type of action determines the path automatically, so each request only goes through what it actually requires.

Why the existing system does not cover it

Most organizations already have a personnel or payroll system that stores the result of an action once it's finalized: the new title, the new pay rate, the termination date. That system is built to hold the outcome, not to manage getting there. It has no way to know that this particular request is a new hire needing IT provisioning while that one is a pay adjustment needing only a department head's sign-off. So the actual approval, the sequence of people who have to review and sign off before the system record gets updated, happens somewhere else entirely: a fillable PDF emailed from person to person, each one responsible for remembering to forward it to the next.

How organizations handle it now

In most organizations, an employee's manager or HR fills out a form, often a PDF, describing the requested action and emails it to the first approver. That approver reviews it, signs, and forwards it to the next person in the chain, whether that's a department head, HR, or payroll. If someone in that chain is out of the office, on leave, or simply slow to get to their inbox, the request sits, and nobody downstream can see where it is or whether it's stuck.

Where it goes wrong

An employee's transfer to a new department gets approved by their current supervisor and forwarded toward HR. The PDF sits in someone's inbox for four days while they're at a conference. Nobody else in the chain can see it's arrived, or that it hasn't moved, because the only copy that exists is the one sitting in that inbox. HR eventually gets a call asking why the transfer hasn't gone through, and has no way to answer except to start emailing around and asking.

What doing it well actually requires

The routing has to know what kind of action it's looking at, not just that it's a personnel action. A pay adjustment, a promotion, a transfer, and a separation are all personnel actions in the broadest sense, but they don't need the same approvers or the same downstream steps. The City of Apopka, Florida rebuilt its personnel action process around exactly this distinction: requests route differently depending on the type of action selected, so a new hire that needs IT and security provisioning follows a different path than a simple pay adjustment that doesn't.

Sequential approval has to be automatic, not dependent on whoever has the file remembering to move it. Apopka's previous process relied on downloading, completing, and emailing fillable PDF forms from person to person. Once a PDF was emailed, nobody else could see where it was, and a single person being out of the office could stall the entire action for days. The rebuilt process routes each request automatically, in sequence, to the department head, HR, and finally payroll, with a notification sent at every stage.

The record has to be built once, not re-typed at every stop. In Apopka's paper process, the same employee data had to be manually re-entered from the completed PDF into the city's other systems at each step, creating real risk of transcription errors. Built-in validation, mandatory fields, dropdowns, specific formatting, catches errors at the point of entry instead of after the fact, so the data only has to be right once.

A pay-related action isn't one thing either. A routine step increase, tied to length of service and applied on schedule, isn't the same request as a reclassification, where a position's grade changes because its duties have grown or changed. A reclassification usually needs a compensation review and a written justification before it's approved, not just a supervisor's signature, and it's different again from a promotion, which typically means the employee was selected for a different, higher-level position rather than having their current one re-evaluated. Treating every pay-related request the same way means either a routine step increase waits on a review it doesn't need, or a reclassification gets approved without the justification it's supposed to require.

The result has to be a complete, time-stamped record of who did what, and when. Apopka's rebuilt process reduced the average time to process a personnel action request from 10 to 12 business days down to about 2. It replaced the old inbox-by-inbox guessing game with a real-time view everyone in the chain can check. Every action now carries a complete, time-stamped history: who initiated the request, who approved it, when, and what data changed at each step.

Common questions

Questions we hear from every HR office.

Does a promotion need to go through the same approval process as a separation?: Not really, even though both start as a request to change an employee's status. A promotion typically needs a department head and HR to sign off. A separation needs those same approvals plus steps a promotion doesn't, like revoking system access. Treating every personnel action as identical either slows down the simple ones or lets a complex one skip a step it actually needed.
What happens if one approver in the chain is out of the office?: In a paper or email-based process, the request usually just waits, since the next person can't act on something they don't have yet. A process where every approver can see the request and its current status as soon as it's submitted doesn't depend on one person's inbox to keep moving. The delay, if there is one, is at least visible instead of invisible.
Why does a new hire need a different approval path than a pay adjustment?: A new hire typically triggers steps a pay adjustment doesn't, most commonly IT provisioning and building or system access, in addition to the usual HR and payroll sign-off. Routing every action through the same generic path means either the new hire's provisioning steps get bolted on manually, or a pay adjustment gets held up waiting on approvals it was never going to need. Once that hire is approved, a separate question follows: getting the actual onboarding paperwork to every office that needs it.
Who defines which approval path each type of action follows, and what happens when that needs to change?: The organization does, without having to build anything itself. The paths are set up around how approval authority is already assigned: which actions a department head signs off on alone, which need HR review, which touch payroll. When that changes, a new approver, a restructured department, an action type that didn't exist last year, the routing changes with it. The paths should describe how the organization works today, not how it worked when the form was first designed.
How do you keep employee data accurate when it has to be entered into multiple systems?: The biggest source of error is usually re-entry: someone retyping the same information from a completed form into a second or third system, a step where transcription mistakes are easy to make and hard to catch. Capturing the data once, with validation at the point of entry, removes that re-entry step rather than trying to catch the errors it produces after the fact.
What does an auditor or a records request actually need to see for a personnel action?: Generally, who initiated the request, who approved it and when, and what specifically changed at each step, not just the final outcome. A record that only shows the end result, the new title or the new pay rate, doesn't answer those questions on its own; the approval sequence itself has to be part of what's kept.

How Flow Forms handles it

Flow Forms routes a personnel action request based on what kind of action it actually is, sending a promotion down one path, a new hire down another that includes IT and security provisioning, and a separation down one that puts revoking access in front of the office that owns it, without anyone sorting that out by hand. Each request moves through its approvers automatically, with a real-time view everyone in the chain can check instead of an inbox only one person can see.

The City of Apopka, Florida rebuilt its personnel action process this way and cut the average time to process a request from 10 to 12 business days down to about 2. Every action now carries a complete, time-stamped record: who started it, who approved it, when, and what changed at each step.

See how it would work for your organization →