How to build a headcount request tracker

What matters here

• A headcount tracker is four parts: a request with a budget line, an approval path including finance, one shared status model, and reconciliation against the plan.
• Recruiting and finance must read the same record. Two lists kept in sync is the problem, not the solution.
• Distinguish backfill from new headcount at request time. They have different approval paths and different budget consequences.
• A role approved is not a role budgeted. Capture the funded start month, because six months of salary and twelve are different numbers.
• Track time from request to approval separately from time to fill. Hiring managers blame recruiting for delays that happened before the role was opened.
• The tracker holds compensation ranges and organisational plans, so scoped access is a requirement rather than a nicety.

Who this is for

You run people operations, recruiting or finance. You already have a headcount plan. What you want is a single answer to how many roles are approved and where each one is, that nobody has to reconcile before a meeting.

How it works in practice

One record per role, from the moment somebody asks for it to the day someone starts.

1. 1

   A manager requests a role against a budget line

   With the level, the salary range, whether it is new or a backfill, and the month the budget funds it from.

2. 2

   It is checked against the plan

   Matching a plan line or not. Off-plan hiring is not wrong, it just has to be visible.

3. 3

   Approval includes finance, before the offer

   Routed by level and annualised cost, with deputies so nothing waits on someone travelling.

4. 4

   Recruiting and finance use the same record

   One status list, two views over it. No reconciliation, because there is nothing to reconcile.

5. 5

   The timeline splits honestly

   Request to approval, approval to open, open to offer, offer to start. Most perceived recruiting delay happens before the role was opened.

6. 6

   The cost impact is projected from funded start months

   So finance can see the in-year and annualised effect of everything currently approved.

1. 1

   A request finance can actually act on

   The budget line, and the field everybody forgets.

   Copy

   In this Helix project, build me a headcount request tracker.
   
   A manager asks for a role, so capture: title, level, team, cost centre,
   location, employment type, salary range, the business case, and the
   priority. Require them to say whether it is a new role or a backfill at
   the moment they create it, and treat those differently everywhere. They
   have different approval paths and different budget consequences.
   
   Now the field almost every tracker misses. Ask for the month the budget
   funds the role from, not a target start date, and derive the in-year cost
   from it. A role starting in month ten costs a quarter of one starting in
   month one, and approving a role is not the same as approving twelve months
   of salary.
   
   Let me load the headcount plan, link each request to a plan line where one
   exists, and flag requests that match nothing. Off-plan hiring is not wrong.
   It just has to be visible.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. Funded start month is the field everyone skips and finance always needs.

2. 2

   Get finance in before the offer, not after

   Approval routing, and what happens when someone edits an approved request.

   Copy

   Route approvals through rules I can edit: based on level, cost centre and
   annualised cost, producing an ordered list of required approvers. Always
   include finance above a threshold I set. Finance approving after an offer
   is out is the failure this whole app exists to prevent.
   
   Give every approver a deputy with automatic reroute after a set number of
   days, and show the requester exactly where their request is sitting and
   with whom.
   
   Record every decision with the approver, timestamp, reason, and a snapshot
   of the request at that moment. Then do the unpopular but necessary thing:
   if anyone edits the salary range, level or start month after approval,
   reset the affected approval steps. Without that, roles get approved at one
   level and recruited at another, and nobody notices until the offer.

3. 3

   One record, two views

   Where recruiting and finance stop disagreeing.

   Copy

   Use a single status list for the whole life of a role: requested, approved,
   open, in process, offer out, offer accepted, filled, on hold, withdrawn,
   cancelled. Do not create a parallel recruiting status. Two lists kept in
   sync is the problem, not the solution.
   
   Record every transition with a timestamp and who made it. Put the
   recruiting fields on the same record: recruiter, posting link, candidate
   count, current stage, offer details, accepted date, actual start date.
   
   Then build two views over that one dataset. Recruiting sorts by stage and
   age. Finance sorts by cost impact and funded start month.
   
   And derive the timings separately: request to approval, approval to open,
   open to offer, offer to accepted, accepted to start. Reporting those apart
   changes the conversation in a hiring review more than any other number
   here, because most of what gets called slow recruiting happened before the
   role was opened.

   Worth knowing. Splitting request-to-approval from time-to-fill is the single most useful report in this app.

4. 4

   Answer how many people we are hiring

   Reconciliation, and the screen you will want on a bad Tuesday.

   Copy

   Report plan versus approved versus filled, by team and quarter, with the
   gap shown in both roles and money.
   
   Project the monthly cost impact from funded start months, so finance can
   see the in-year and annualised effect of everything currently approved.
   List off-plan approvals separately with their approvers and reasons.
   
   Age the pipeline: approved roles not yet open, and open roles past a
   threshold, each with an owner.
   
   Add a hiring freeze mode that puts every non-exempt request on hold with a
   reason and notifies the requesters. You will need it one day and you will
   not want to build it that morning.
   
   And let me export a snapshot for a board pack, and keep it, so a later
   correction does not change a number that has already been reported.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Workday>. Read the current org, managers and levels, and write filled
   roles back when somebody starts.
   
   <NetSuite>. Read the headcount plan and cost centres, which is what makes
   a request more than a wish.
   
   <Greenhouse>. Pull recruiter, stage and offer status onto the same record,
   rather than a parallel list.
   
   <Slack>. Chase approvers and tell requesters where their role sits.
   
   <Okta>. Read the group that says who is in finance or HR, which is what
   the app checks before showing a salary range. These are the most sensitive
   fields in the library.
   
   <Gusto>. Read actual payroll cost per role, so the in-year projection is
   real rather than a band.
   
   <Google Sheets>. Take the approved plan in the form finance built it, so
   the tracker agrees with the file the CFO signed off.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Salary ranges and headcount plans are among the most sensitive data you hold, so set Access Control before sharing: managers see their own team, finance and people operations see everything.

What it connects to

This is the app where recruiting and finance stop disagreeing, so it has to read from both.

• Workday

  Read the current org, managers and levels, and write filled roles back when somebody starts.

• NetSuite

  Read the headcount plan and cost centres, which is what makes a request more than a wish.

• Greenhouse

  Pull recruiter, stage and offer status onto the same record, rather than a parallel list.

• Slack

  Chase approvers and tell requesters where their role sits.

• Okta

  Read the group that says who is in finance or HR, which is what the app checks before showing a salary range. These are the most sensitive fields in the library.

• Gusto

  Read actual payroll cost per role, so the in-year projection is real rather than a band.

• Google Sheets

  Take the approved plan in the form finance built it, so the tracker agrees with the file the CFO signed off.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides