Migrate from PeopleForce to Crelate

PeopleForce Employee records map to Crelate Contact records. We extract all standard fields (name, email, phone, hire date, employment status, department, manager) and map them to the corresponding Crelate Contact fields. The manager relationship resolves to a Contact lookup using the manager's email as the dedupe and match key. Active and inactive status migrates; status labels are preserved in a custom field pf_original_status__c for audit. Custom fields on the Employee object are mapped to Crelate custom fields on Contact under Core Records settings.

PeopleForce profile photos, bio data, emergency contacts, and skills live as sub-objects under Employee. We migrate bio text and emergency contact information into Crelate Contact fields where supported, and store structured profile data in a custom field set or serialized JSON in a Crelate long-text custom field. Profile photos do not migrate automatically; we deliver a file inventory with filename mapping for manual re-upload if photos are required in Crelate.

PeopleForce Positions capture job title, department, employment type, and effective dates per employee. Job title maps to Contact.JobTitle, department maps to a Crelate custom picklist field pf_department__c, and employment type maps to a custom picklist field pf_employment_type__c. Effective dates for position history are stored as a custom text or JSON field since Crelate Contact does not natively support position effective-date timelines.

PeopleForce PeopleRecruit vacancies map to Crelate Job records. Vacancy name becomes Job title, vacancy status maps to Job status (Open/Closed), and the PeopleForce pipeline stages map to Crelate pipeline stages or status values. Multiposting configurations and job board connections are not portable; we document them as configuration items for the Crelate admin to re-configure under Settings > Jobs > Pipelines.

PeopleForce applications submitted against vacancies map to Crelate Candidate records linked to the corresponding Job. Application status (new, screening, interview, offer, hired, rejected) maps to Crelate Candidate status values. Candidate contact information is merged into the Contact record; the Candidate record tracks the application-specific timeline against the Job. We resolve duplicate Contacts by email match during Candidate import.

PeopleForce employee documents (contracts, ID copies, certifications) are stored per Employee record. Document metadata (filename, file type, upload date, related employee) migrates into Crelate as ContentDocument records linked to the Contact. The actual file content migrates via Crelate's document storage where accessible, or is delivered as a file package with a document mapping index for manual re-upload if the PeopleForce API does not expose binary file content directly.

Leave policies, accrual rules, and balance data have no Crelate equivalent. Crelate is an ATS and recruiting CRM with no leave management module. We inventory all active leave policies with their type, accrual rate, and carry-over rules as a structured written document for the customer's HR admin to evaluate HRMS alternatives (BambooHR, Factorial, HiBob) or a dedicated leave management integration post-migration.

Leave request history (approved, pending, denied) is not migrated because Crelate has no leave request object. Historical leave request data is exported as a CSV report from PeopleForce, delivered as a supplementary data file, and stored alongside the migration package for audit or HR reporting purposes if required.

Performance review cycles, review forms, submitted feedback, and scores have no Crelate equivalent. Crelate ATS does not include a performance review module. We export completed review records as structured data and deliver them as a written inventory document listing each review cycle, the form builder configuration, and the submitted scores, so the HR admin can evaluate Crelate integrations with performance tools (Lattice, 15Five, BambooHR Performance) as a separate post-migration step.

Kudos records given between employees in PeopleForce are supplemental recognition data with no Crelate equivalent. These are exported as a supplementary CSV with sender, recipient, message, and timestamp, delivered as part of the migration package for the customer's records. If Crelate's Tags feature is in use, kudos data can be tagged on the relevant Contact records as a manual post-migration step.

Onboarding task templates and completion status from PeopleForce are not portable. The checklist templates are platform-specific and require re-implementation in Crelate or a dedicated onboarding workflow tool. We deliver a written inventory of all active onboarding checklists with task names, responsible parties, and due dates so the customer can configure Crelate Tasks or a third-party onboarding tool (Trakstar, BambooHR Onboarding) post-migration.

Offboarding checklists and completion records have no Crelate equivalent and are not migrated. Exit interview data and offboarding task completion are exported as structured CSV and delivered alongside the migration package. The customer can use Crelate Tasks for ad-hoc offboarding task tracking if needed, but this requires manual setup post-migration.

PeopleForce custom workflow triggers and automated sequences are built on the platform's attribute-based workflow engine and are not portable to Crelate. Crelate's Automation and Sequencing feature (available on Business Plus) uses a different trigger and action model. We deliver a written inventory of every active PeopleForce Workflow documenting its name, trigger conditions, actions, and the recommended Crelate Automation equivalent. The customer or a Crelate implementation partner rebuilds these post-migration.

PeopleForce custom fields on Employee records are inventoried during discovery and mapped to Crelate custom fields on Contact. We match data types: PeopleForce text maps to Crelate Short/Long Answer, picklist maps to Crelate Picklist, date maps to Crelate Date Field, number maps to Crelate Numeric. The Crelate Logical Name (API field name) is set during custom field creation, and the mapping is validated against a sample of 25-50 records before full migration.