// Recruitment Technology, Migrations

Client or Candidate? Seven Data Model Decisions Agencies Get Wrong Once

The bottom line

A CRM data model decides what your recruiters can see, search, filter, and report on. It gets set in the first week of implementation, not the first year of use.

Seven structural choices cause most of the long-term damage. They start with dual-role contacts, umbrella companies, shared ownership, and clients that span several entities and currencies.

Settle each one before anyone configures a pipeline. Every choice left open becomes a workaround your team repeats thousands of times.

Why structure outlives every workflow you build on top of it

Configuration is reversible. Structure is not.

A pipeline stage can be renamed on a Tuesday afternoon. The rule about whether one person can be a client and a candidate at the same time cannot. By the time anyone questions it, thousands of records already depend on the answer.

Most agencies never make that call deliberately. The CRM data model emerges from whichever answer came fastest during implementation. The business then works around it for the next five years.

Every agency has one contact record that two desks refuse to merge, and a quiet agreement never to mention it.

Operations directors raise this with us more than any other setup question. The pattern is consistent. Structural decisions get made by people solving a Tuesday problem, and the commercial cost lands two years later.

Which seven data model decisions should you settle first?

Settle the ones that cannot be reversed without touching every record in the system. The seven below surface in almost every agency implementation, and each one changes what your reporting can answer later.

1. Whether a person can be a candidate and a client contact at the same time
2. Where an umbrella company sits when the end client is someone else
3. How one client spanning several entities and currencies is represented
4. Who owns a record when two desks work the same account
5. Whether candidate status belongs to the person or to the application
6. What counts as one job when contracts extend and mandates run to several hires
7. What earns a custom field, and what stays in a note

1. Is a senior contact a candidate record, a client contact, or both?

Both, on one record. A person is one entity in your database. Client or candidate is a role they hold at a point in time.

The commercial logic is clearest on a full desk. 41.10% of agency recruiters work in full-desk roles, running business development and delivery across the same accounts. The same name lands on both sides of the ledger in one week.

Split that person into two CRM records and the two drift apart immediately. Email sync updates one. The call notes land on the other. Six months later nobody can say which record holds the current mobile number.

The expensive version shows up in BD. A consultant pitches a spec CV to a hiring manager they placed two years ago. The relationship already exists, but the placement sits on a record their search never touched.

One person, one record, with roles layered on top. That also keeps your recruitment database searchable as a single population rather than two half-populations that each look thin.

2. Which company record does an umbrella company belong to?

Not the client record. An umbrella company is a supplier inside your payment chain. Model it as the client and your account reporting breaks from the first placement.

The scale is not marginal. HMRC estimated that 700,000 workers were engaged by umbrella companies in 2022/23. From 6 April 2026, joint and several liability for PAYE reaches the agency that contracts with the end client.

Most legacy setups flatten everything into one company object with a type field. It holds until the same umbrella appears across 40 clients. Then your account reporting starts counting a payroll provider as a key account.

Structured contract setup fixes it. End client, project, contractor, contract type, dates, and financial details are captured as separate inputs in contract recruitment software. The intermediary never has to pose as the buyer.

That makes the modeling question a compliance question as well. Your system has to tell four parties apart on a single contract placement:

• The end client, where the work happens and where the relationship sits
• The contracting entity that signs your terms and receives the invoice
• The intermediary that employs and pays the worker
• The managed service layer that controls access to the hiring manager

3. What happens when one client spans several entities and currencies?

Your reporting splits, and nobody can say what the account is actually worth. One commercial relationship routinely runs across several legal entities, several countries, and several currencies.

A PSL signed at group level. Purchase orders issued by a subsidiary. Fees invoiced from two entities, in different currencies, on different payment terms, with different rebate periods attached.

A flat company object cannot express any of that. You end up with six company records that share a name and nothing else. An account director rebuilds the group view by hand every quarter.

Decide the hierarchy now. A parent account owns the relationship and the commercial terms, and child entities own contracts, invoices, and currency. Then recruitment dashboards can roll revenue up to the group and drill back down to the entity.

Currency belongs on the placement rather than on the agency. Rate, fee, margin, and rebate value each record what was agreed, in the currency it was agreed in. Conversion happens at reporting time.

4. Who owns a record when two desks work the same account?

Ownership belongs to the relationship, and your model needs room for more than one owner. The moment a candidate is sourced by one desk and placed by another, single-value ownership starts costing money.

This is a fee split problem before it is a data problem. If the system records one owner, somebody argues about credit at month end. Somebody else keeps the real version in a private spreadsheet.

Nothing sharpens data quality faster than a commission dispute, and nothing degrades it faster than the fear of one.

So decide what ownership actually controls. Visibility, editing rights, commercial credit, and reporting attribution are four separate things. Collapsing them into one field is why recruiters hide warm candidates.

Keep attribution on the business development record and on the placement, where it can be split between desks. Stamping one name across the whole company solves nothing.

5. Does candidate status belong to the person or to the application?

To the application, every time. A person is never simply interviewing. They are interviewing for one role, shortlisted on a second, and sitting in a talent pool for a third.

A single global status field on the person record is the most common early mistake. It survives because it looks tidy in week one. It breaks the first time a candidate runs in two pipelines at once.

The consequence is measurable. Submission-to-interview ratio, time-to-send, send-to-placement ratio, and fall-off rate all read from application-level data. An agency carrying person-level status cannot calculate them without manual cleanup.

Rebate periods make the point sharper. A fall-off attaches to one placement on one role. It does not attach to a person who has been placed three times.

An AI-powered ATS should let the same person sit at a different stage in every pipeline they appear in. No copying, and no duplicate records.

The split is straightforward once someone writes it down:

• Person level: contact details, right to work, notice period, salary expectations, consent basis, and do-not-contact flags
• Application level: stage, submission date, client feedback, agreed rate, interview history, and outcome

6. How does one job record handle extensions, multi-hire mandates, and rebookings?

Decide whether a job is the requisition or the seat, then write the rule down. A retained mandate for eight hires can be one job with eight placements, or eight jobs with one each. Fill rate means something different in each version.

Contract desks feel this first. An extension is either a new contract against the same job or an amendment to an existing one. That choice decides whether your starters, runners, finishers, and extensions reconcile at period end.

Rebookings ask the same question with a different label. A contractor returns to the same client six months later. The system has to treat that as a new placement or as a reactivation of the old one.

None of these answers is wrong on its own. Choosing late is wrong, because by then half the desk has done it one way and half the other.

Board-level reporting depends entirely on this one choice. It is why contract staffing software lives or dies on its data structure rather than its interface.

7. When does a detail deserve a custom field instead of a note?

When you will filter, report, or automate on it. Everything else belongs in the conversation record, where it can be read without anyone maintaining it.

Custom field sprawl is the slowest of these failures and the most visible. An agency ships 90 custom objects and fields in year one. Eleven get populated, and recruiters learn to scroll past the rest.

Each of those fields was created because the detail would otherwise be lost. That is no longer true.

Capture changed that calculation. Conversations now write themselves into the record, so detail survives without a field to maintain. That capability sits at the center of Atlas. It is an AI-powered CRM and recruitment platform that uses agentic AI to take admin off the desk. Calls, emails, meetings, and messages feed a searchable recruitment AI memory, and the detail stays findable.

85% of agency recruiters already use AI to handle updates in their ATS or CRM. That shows where the field maintenance work was going. Fields that exist only so someone can type into them go stale first, and data decay finishes the job.

Four questions decide whether a detail earns a field. If the answer is no to all four, it belongs in a note:

• Will a recruiter filter or search on this during a live role?
• Does a report, a dashboard, or a client SLA depend on the value?
• Will an automation or an AI agent act on it?
• Can it be captured once and kept current without manual entry?

What is a CRM data model, and why does it decide your reporting?

A CRM data model is the set of objects your CRM system stores. It also covers the relationships between them and the data types each field accepts. In recruitment the standard objects are people, companies, jobs, applications, and placements, with custom objects layered on top.

Those objects are the vocabulary your whole business argues in. A report can only ask questions the model can express, so a missing relationship is a missing answer, permanently.

The cost is well documented outside recruitment. Gartner research puts it at at least $12.9 million a year on average for poor data quality. Inconsistency across siloed sources is named as the hardest problem of the set.

Agency recruitment makes that harder than most sectors. The valuable CRM data arrives as conversation rather than as form input. A common data model gives every team one definition of a client, a lead, a live role, and a placement. That shared definition is where CRM adoption usually fails.

So decide the objects before the fields, and the fields before the automations. Every layer inherits the constraints of the one beneath it. A clean CRM database cannot rescue a model that cannot describe your business.

How do you pressure test a model before configuration starts?

Run your four most awkward accounts through the proposed model on paper, before anyone builds a pipeline. Use the messy ones rather than the clean example from the demo.

The demo always uses a single-entity client with one hiring manager and no umbrella. The candidate has never worked with you before.

One question outranks the others: what can still be changed after go-live. Platforms let you add fields forever and change relationships almost never. That is why the data migration conversation belongs at the start of an implementation rather than the end.

Bring the people who will live with the answers. Your operations lead, the contract desk, finance, and whoever owns reporting should all be there. Each will raise a case the implementation consultant has never seen.

Then work through the questions that otherwise surface in month nine:

• Can one person hold a client role and a candidate role on a single record?
• Where does an umbrella company or employer of record sit, and can one serve 40 clients?
• Can a parent account roll up revenue from child entities billing in different currencies?
• Can two recruiters hold attribution on one placement, with the split recorded?
• Can a candidate sit at a different stage in every pipeline they appear in?
• Does an extension create a new record, and does fill rate still hold either way?
• What happens to a custom field when the person who requested it leaves?
• Which of these can be changed after go-live without a full data migration?

Frequently asked questions (FAQs) on recruitment CRM data model decisions

The structural choices that decide what your recruiters can see

Seven decisions inside your CRM data model, settled in a week, govern what your agency can measure for years. None is difficult in isolation, and all of them are expensive to revisit once the records exist.

Write them down before configuration starts and test them against your hardest accounts. Give one person the authority to settle the arguments.

Structure only holds when the records filling it stay complete. Automatic capture does that work in the AI-powered CRM from Atlas, where calls and emails land on the right record. A dual-role contact then carries one history instead of two partial ones.

Worth an hour with your operations lead before the next configuration call.