Migrate from Zinc to Microsoft Dynamics 365 Sales

Zinc's Candidate record maps to Dynamics 365 Contact. Email is the primary identity field used for merge-key resolution against existing Dynamics 365 contacts. If a matching email exists in Dynamics 365, the records merge; otherwise a new Contact is created with a custom field preserving the Zinc Candidate ID.

If the Zinc candidate has not yet advanced to a formal hiring stage, FlitStack creates a Lead record in Dynamics 365 rather than a Contact. The split logic uses a check_status field: candidates with zero completed checks route to Lead; one or more completed checks route to Contact.

This is the primary non-standard mapping. Zinc's Check record has no native Dynamics 365 equivalent — we create a custom Dataverse table called Background_Check__c with fields for check type, status, result, verifier name, verification date, and notes. The entity lives inside a managed solution for clean promotion across Dynamics 365 environments.

Each Background_Check__c record carries a lookup field (ContactId__c) pointing to the Dynamics 365 Contact that corresponds to the Zinc candidate. The lookup resolves after the Contact is created or matched, enforcing referential integrity. Records without a resolvable candidate email are flagged for manual review.

Zinc's status picklist (Pending, In Progress, Complete, Cancelled, Failed) maps value-by-value to a custom picklist on Background_Check__c.Status__c. Each value retains its original display label from Zinc to maintain reporting continuity. Probability weights for pipeline forecasting are assigned per status value within the Dynamics 365 picklist definition, allowing sales managers to view expected close rates based on verification status.

Zinc supports multiple check types: Employment Verification, Education Verification, Criminal Background, Reference Check, Credit Check, etc. Each type maps to a corresponding picklist value on Background_Check__c.CheckType__c. If Zinc uses a custom check type not pre-defined in our mapping table, we add it as a new picklist value during schema setup.

Check results (Clear, Consider, Discrepancy, Unable to Verify, etc.) map to a custom picklist on Background_Check__c.Result__c. The value mapping preserves the result label from Zinc exactly to maintain reporting continuity. Results are stored as custom picklist fields on the Background_Check__c record and can be used in Dynamics 365 views, reports, and Power BI dashboards without requiring any transformation or re-labeling.

Zinc stores verifier name, title, company, phone, and email. We map these to individual custom fields on Background_Check__c: VerifierName__c, VerifierTitle__c, VerifierCompany__c, VerifierPhone__c, VerifierEmail__c. Optionally, if the verifier is a known Contact in Dynamics 365, we create a secondary lookup to that Contact record.

Zinc's free-text notes and reference comments migrate as a large-text custom field (Notes__c) on Background_Check__c. This preserves the original text verbatim. We do not parse or normalize this field because the structure is non-uniform and normalization could lose context. The field is surfaced in the Dynamics 365 form for recruiter review.

Zinc tracks the requester (recruiter or hiring manager) who initiated each check. This data has no native Dynamics 365 equivalent since OwnerId maps to the Dynamics 365 user who owns the record. We preserve the Zinc requester as custom fields on Background_Check__c for audit continuity. The actual Dynamics 365 record Owner is set during migration based on the requester's email match to a Dynamics 365 user.

Zinc maintains OAuth integrations with ATS platforms (Greenhouse, BambooHR, Lever) that push candidate data bidirectionally. Dynamics 365 has no native ATS connector. These integrations are documented by FlitStack with the OAuth endpoints and trigger logic, then rebuilt manually as Power Automate flows or Dataverse connector apps after the migration.

Email is the merge key used to match Zinc candidates to existing Dynamics 365 contacts. FlitStack applies email normalization before matching: removing periods from Gmail addresses (john.smith @ gmail.com → johnsmith @ gmail.com) per RFC 5321 to reduce false-positive duplicates.

Direct name field mapping from Zinc's first_name to Dynamics 365 Contact.FirstName. FirstName in Dynamics 365 has a 120-character limit, which comfortably accommodates most candidate names. If a null first name is encountered in Zinc, FlitStack preserves it as an empty string in Dynamics 365 rather than skipping the field, ensuring data completeness.

Direct name field mapping from Zinc's last_name to Dynamics 365 Contact.LastName. LastName is a required field in Dynamics 365, so FlitStack validates this field during the extraction phase. If Zinc returns a null or empty last name, FlitStack sets a placeholder value ('Unknown') and flags the record for manual review before finalizing the migration, ensuring no records fail validation due to missing required fields.