Migrate from Attendo to Zendesk

Attendo employee records map to Zendesk User objects. We extract name, email, role, department, start date, and active/inactive status. The email address serves as the dedupe key during import. Custom properties on the employee record migrate as user fields or custom_fields on the Zendesk User object. Historical employment status changes (terminated, re-hired) are preserved as a custom field employment_history__c in JSON-serialized format.

Attendo clock-in/out events and work-time entries map to a custom object we create in Zendesk called Attendance. Each record includes clock_in, clock_out, work_duration_hours, break_minutes, overtime_hours, and exception_flags. We create a lookup relationship field linking each Attendance record to the Zendesk User (the employee). The custom object is deployed via the Custom Objects API before any data is imported, and records are loaded in reverse-chronological batches using the Zendesk REST API with exponential backoff on rate-limit responses.

Attendo absence plans (sick, vacation, unpaid) with accrual rates and current balances map to a Zendesk custom object called Absence Balance. Each record stores absence_type, accrual_rate_per_year, current_balance_hours, carryover_hours, and ceiling_hours. The absence_type maps to a drop-down custom field. We preserve the balance snapshot at migration time; the accrual calculation logic is documented for the customer's admin to configure as Zendesk SLA policies or custom business rules post-migration.

Attendo flexible PTO configurations (accrual rates, carryover rules, ceiling limits) export as a separate custom object called PTO Policy. This is a reference-data object that applies to multiple employees. We create lookup relationship fields from Absence Balance records to their governing PTO Policy. Per-employee policy overrides are stored as a separate field on the Absence Balance record.

Attendo projects with task schedules, timelines, budgets, and progress indicators map to a Zendesk custom object called Project. The project object schema includes project_name, start_date, end_date, budget_amount, cost_allocated, and progress_percent. We deploy the Project custom object via the Custom Objects API with a title field set to project_name.

Attendo tasks belonging to projects map to a Zendesk custom object called Task with a lookup relationship back to the parent Project. Task fields include task_name, assignee (lookup to User), deadline, status, and parent_project (lookup to Project). Attendo task status values map to the Zendesk Task custom object's status field with a status-migration map defined during discovery. Multiple tasks per project are supported via the 1:N relationship.

Attendo project-level cost data (labour, materials, fixed-cost line items against budgets) maps to a Zendesk custom object called Project Cost with a lookup to the parent Project record. Cost fields include cost_type (labour, materials, fixed), amount, date_incurred, and cost_category. Budget comparison requires the total budget_amount from the parent Project custom object and is computed post-migration in Zendesk Explore or a reporting tool.

Attendo employee contracts, offer letters, and supporting documents export as binary files. We re-associate them in Zendesk by uploading to the Zendesk User record'sAttachments endpoint using a deterministic file-to-user mapping derived from the employee identifier. Files exceeding 1MB are flagged for the customer to upload manually since Zendesk's API excludes files over 1MB. PDF and DOCX formats are supported; non-standard formats are noted in the reconciliation report.

Attendo's internal system messaging stores inter-employee communication tied to workflows. This is a transient communication channel and does not constitute a formal business record under standard migration scope. We do not migrate internal messages. We flag this gap in the deliverables inventory so the customer's admin is aware that historical workflow-linked messages will not appear in Zendesk.

Attendo configurable fields on employee records export alongside the employee data. We preserve the field schema (name, type, options) and map each to a corresponding Zendesk User custom field of the equivalent type. Drop-down becomes Zendesk drop-down, multi-select becomes Zendesk tagger, checkbox becomes boolean, numeric becomes integer, and date becomes Zendesk date. The schema definition is delivered as a reference document for the admin to create in Zendesk Admin Center before migration begins.