An employee's HR history was scattered across spreadsheets, folders and payroll separately for candidates, current staff and departed employees, and each position needed its own document package that nobody tracked systematically.
A single profile is created as early as the job application, carries through hiring, transfers and termination without re-creating the record, requests documents tailored to the specific position, and shows HR, the manager, accounting and the employee only their own slice of the data.
The company got one continuous history for every person from application to archive, and a legally required document can no longer slip through unnoticed - the portal blocks onboarding until it's uploaded.
Headcount is only part of the picture
A typical HR spreadsheet answers the question of who works at the company right now. But a person's journey starts earlier - with an application for a vacancy - and often ends long before the hire. Some candidates fail the screening, others withdraw on their own. Those who are hired are later moved between positions, sent on leave, and let go.
New data and documents appear at every stage. If you keep them separately, HR has to reassemble the history from scratch across spreadsheets, folders, and payroll: who the person was when they arrived, what requirements applied to their position, what changed after a transfer, and who is allowed to see their documents.
The scale quickly grows beyond the current headcount. There are orders of magnitude more candidates in the database than active employees, and over the years a separate layer of former employees builds up. Their records matter to the company too: HR history should not disappear along with a change of status.
Without a shared profile, the same information starts to live in several versions. A candidate updated their details in the questionnaire, HR saved an old copy in their own spreadsheet, the documents ended up in a separate folder - and now it is unclear which source counts as current. The portal is needed even before someone joins the staff, so that both sides work from a single history and do not reassemble it at every transition.
The profile appears before the employee
Take a person who applied for a driver vacancy. They are not an employee yet: screening, documents, and a hiring decision are still ahead. But they already have a profile in the HR portal.
If the screening ends in a rejection, the profile moves to the archive. If the person is hired, that same record keeps living, now as an employee profile. Their case shows the portal's whole idea: not to create separate cards at each stage, but to keep one history from the first contact to the departure.
The candidate fills in the profile themselves and sees what information and documents are expected of them. HR works with the same record, checks the set, and moves the person to the next stage. A rejection does not erase the previous work, and a hire does not require moving data into a new employee card.
One record survives every change of status
If a candidate is hired, a position, a status, and HR documents are layered on top of the already-filled profile. A transfer changes the position, a departure changes the status. The profile itself stays the same.
What goes to the archive is not an empty line with a surname. The whole HR history stays there: when the person arrived, which positions they held, and what documents accompanied them during that time.
The archive closes both branches of the process. It holds candidates who were not accepted and employees after their departure. For an active person, the profile keeps accumulating transfers and changes of position, so when you review the history you see not only their last place but their whole path within the company.
The people who run the portal are set up by the same rules. An HR specialist once went through hiring themselves and received an employee profile. There is no separate service door through which administrators enter the system, bypassing the common order.
A driver and an accountant need different documents
At the onboarding stage a one-size-fits-all list quickly stops working. A driver needs an ID, a license of the required category, and medical certificates. If they work with their own vehicle, a registration certificate, insurance, and clearances for specific types of transport are added. An accountant needs different confirmations - a diploma and references, for example. For a simple position an ID may be enough.
That is why the portal requests documents not "for an employee in general," but for a specific position. When the position changes, the required set changes too.
These requirements carry different weight. A reference or a proof of qualification may be an employer's internal condition, and the company handles a missing paper by its own rules. A medical certificate for certain work is mandatory by law, and its absence will surface not only inside the HR department but also during an external inspection.
A gap in a set that the law requires cannot be left to the HR specialist's discretion. The portal halts the onboarding before the violation makes it into the HR history.
The rules for each position are set in the system itself, so HR does not have to keep exceptions in their head. It is precisely this dependency between the vacancy, the position, and the documents that makes the solution specific to the employer's processes: a universal questionnaire is not enough here.
One profile looks different for four roles
Inside the profile are personal documents, information about work, hours, and payments. Opening all of it to anyone who logs in would be dangerous, so each role has its own view that matches its real tasks.
| Role | Main working slice | Access boundary |
|---|---|---|
| Employee | Own profile, leave, hours, and payslip | Does not see colleagues' profiles |
| Manager | Their team's employees and their requests | Works within their area of responsibility |
| HR specialist | People's statuses, positions, and HR documents | A specific document may be closed off by a separate permission |
| Accountant | Hours, rate, and the payroll part | Does not automatically get the full set of personal documents |
The restriction also applies inside the profile: access to a person does not yet mean access to every one of their documents. The portal checks not only the user's role and the selected profile, but also the right to open a specific file.
After the hire, the portal stays with the employee
HR history does not end on the day of onboarding. Through the same portal an employee requests leave, a manager makes the decision, and the remaining days are recalculated automatically. Working hours enter the records and take part in calculating pay by rate. The employee opens their payslip in their personal account and sees for themselves which hours they were paid for.
These operations are tied to the same person and their current position. Hours do not have to be transferred separately into payroll, and the leave balance does not have to be reconciled by hand after every approval. The employee sees the result in the same account where their HR history is kept, and does not need to contact accounting for every breakdown.
The main advantage for the HR function is continuity of data. Information is not moved between cards at hiring, transfer, and departure, so different departments work from a single history, while fine-grained permissions open up only the necessary part of the profile to each participant.
In the end, the same profile answers different questions in different years. To a candidate it shows what is needed for onboarding. To an employee - leave, hours, and payments. To HR and accounting - their part of the workflow. After a departure it preserves the context that would otherwise have to be reconstructed from folders, emails, and copies of spreadsheets.
Flexibility requires setup
The portal knows which documents a driver or an accountant needs only because these rules are described in advance for a specific employer. A company's internal requirements and the documents mandated by law differ between positions, so a ready-made list "for everyone" is not enough.
This is both an advantage and the price of the solution. The system follows the real HR process, but before launch that process has to be worked through and configured: positions, document sets, roles, and access to individual files. If the company's requirements change, the portal's rules have to be kept current too.
Oleksandr
This is a real project, presented anonymized. We deliberately change the identifying details - the industry, the specifics, anything that could point to the client - and we don't reveal the client's name or trade secrets. What stays intact is the substance: the problem we solved and the engineering approach behind it. This case study is here to show the problem and its solution - what we do and how.