Recruitment Apps: When Should an Applicant Become an Employee?

A recruitment app should not turn an applicant into an active employee merely because someone sent an offer. Define the evidence needed for each step: an approved offer, the required signatures, a completed employee record and any separately authorised onboarding actions. These are related events, not one interchangeable status.

This is a software-briefing guide, not advice about when an employment relationship legally begins. Contract terms, signature requirements and local employment obligations need appropriate professional review.

Keep the offer attached to the right application

A person may apply for more than one vacancy. Ask the developer to show which application, role and offer version a response belongs to. A signed document for one role must not silently close a different application or replace a later offer.

Record who may approve and send an offer, and which document is actually presented. If terms change, decide how the previous offer is withdrawn or superseded and how the applicant is informed. A staff member editing an internal field should not alter a document already signed without a controlled process.

The Odoo 19 offer documentation provides a concrete product example: its offer has an expiration date, after which the contract cannot be signed. Your own brief should state what expiry means, which clock applies and who may issue a replacement. Do not assume an expired link proves that the applicant rejected the role.

Distinguish the applicant's signature from completion

Ask which signatures the process requires and how the app knows they are complete. An applicant saying yes in an email, signing a document and receiving the employer's countersignature may be separate events. Use labels that accurately describe the recorded evidence rather than a single optimistic “accepted”.

Odoo documents moving the application to Contract Signed and displaying Hired after all parties have fully signed. That is the documented product workflow, not a universal legal definition of hiring. For your app, specify an owner for an offer awaiting the employer's signature and show what remains outstanding.

Also decide what happens when a signature service is unavailable or its completion notification arrives late. Staff need a reviewable pending state. A delivery error must not automatically mean the applicant declined, and a retry must not create a second hiring case.

Make the employee handover deliberate

The same Odoo guide describes a separate Create Employee action after hiring, with information drawn from the application and contract. This illustrates why a completed offer and a complete employee record should be distinguishable.

Choose the data to transfer and the person responsible for checking it. Keep interview commentary and unrelated applications out of the employee handover unless there is a justified, authorised reason to include them. Decide how to recognise an existing employee record rather than creating another one for a returning worker.

Set the intended start date explicitly. Creating a record today should not, by itself, activate building access, payroll changes or system accounts today. Those actions need their own agreed triggers, permissions and failure handling. Do not promise that a recruitment status alone makes those integrations safe or complete.

Demonstrate the awkward cases before acceptance

Use synthetic applications in your acceptance criteria. Walk through an expired unsigned offer, applicant-only signature, completed signatures, revised terms and a person with an existing employee record. Include a delayed notification and a failed employee-record creation.

For each case, inspect the application status, signed document version, outstanding owner and resulting employee record. The app should explain what happened without inventing a successful handover. Bring your actual recruitment responsibilities to a workflow-app discussion, with legal and HR decisions already identified for the right reviewers.