Migrate from People First to Recruit CRM & ATS

People First employee records map to Recruit CRM candidate profiles. We extract standard fields (full name split into first_name and last_name, job title, department, start_date as hire_date, email, phone) from the customer's CSV export. Where the export contains an employee photo or document URL, we attach it as a ContentDocumentLink to the candidate record. Custom employee properties (employer-specific fields not confirmed in public documentation) require a manual field inventory from the customer before we can confirm mapping completeness.

People First department hierarchies map to Recruit CRM candidate tags (multi-value, searchable) or a custom text field on the Candidate object, depending on whether the customer wants department as a filterable tag or a plain-text attribute. We preserve parent-child department relationships by concatenating the hierarchy path (e.g. Engineering > Backend) into the tag string. The customer selects the strategy during scoping.

PTO balance data from People First does not have a native equivalent in Recruit CRM's candidate model, which is built for recruiting pipelines not HR administration. We map PTO data to a custom number field on the Candidate object (e.g. pf_pto_balance_days__c) and flag in the migration notes that this field is for informational reference only, not for transactional time-off management. The customer should configure a separate HR time-off system post-migration.

Benefits records referenced in People First documentation have no documented export schema and no direct Recruit CRM equivalent. We map benefits data to a combination of custom text fields on the Candidate object (e.g. pf_benefits_package__c, pf_health_plan__c) or as structured notes attached to the candidate record. Benefit data that cannot be extracted programmatically from People First is flagged for manual entry during a post-migration verification window.

People First engagement and recognition records (awards, shoutouts, culture metrics) map to Recruit CRM activity notes and candidate tags. Recognition type maps to a tag value (e.g. recognition_q4_2024), and the recognition narrative maps to an Activity note with a pf_original_engagement__c reference field. Recruit CRM's activity model (calls, emails, tasks, notes) provides a structured home for this data even though the semantics differ from People First's engagement module.

People First admin and end-user accounts map to Recruit CRM user accounts. We resolve users by email match. Any People First user without a corresponding Recruit CRM seat provisioned is placed in a reconciliation queue for the customer's admin to action before the candidate migration begins, because owner or recruiter assignment on candidate records requires an active Recruit CRM User.

No public schema exists for People First custom fields. If the customer has added employer-specific properties to Employee records, we request a complete field inventory before migration scoping is finalised. Custom fields migrate to Recruit CRM custom fields on the Candidate object (up to 15 on Team plan, 20 on Business, 50 on Enterprise), with field type mapped from the source (text, number, date, picklist). We flag any custom field that cannot be exported from People First for manual post-migration entry.

People First conflict resolution case records have no equivalent object in Recruit CRM, which is built for external candidate and client management, not internal HR dispute handling. We do not migrate case records. We deliver a written inventory of open and historical case records (record count, parties involved, resolution status, dates) for the customer's HR admin to assess whether these require a separate HR case management tool or can be archived as documents.

Employee documents (employment contracts, policy acknowledgements, onboarding records) referenced in People First do not have a confirmed export endpoint. We handle file-level transfer only: if the customer can provide a file export or shared folder of documents, we upload them to Recruit CRM as ContentDocument records linked to the corresponding candidate. Any documents that require programmatic extraction from People First's document store cannot be migrated without a manual export by the customer or a screen-scraping approach, which we flag as a risk item.

If the customer has used People First to track internal promotions, role changes, or placement records (for staffing agency use cases), these map to Recruit CRM Placement records. Placement links a Candidate to a Job and records start date, end date, status, and billing information. We apply this mapping only where the customer confirms that People First has been used to track external candidate placements, as this is not the platform's primary function.