Migrate from BlinQ to Salesforce Sales Cloud

BlinQ export-type permanence locks records to Contact or Lead with no bulk reclassification

BlinQ's CRM integration setting lets you choose 'Export as Contact' or 'Export as Lead' per workspace, and once a specific contact record is exported, its type is permanent within BlinQ — a contact exported as a Lead cannot be re-exported as a Contact from the same BlinQ account. During migration planning, FlitStack audits the export-type distribution across your BlinQ workspace to determine how many records will land as Leads versus Contacts. If your BlinQ setup mixed export types without a consistent policy, Salesforce will receive both object types and your admin needs to decide whether to convert some Leads to Contacts post-migration or accept the split model. This is not a data loss issue but a schema-design decision that affects Salesforce reporting and page layouts.

BlinQ has no standalone Account object — company names are free-text strings requiring Account deduplication

BlinQ stores the company name as a plain text property on the contact record with no master Company object and no enforcement of unique or consistent naming. Identical companies may appear with different spellings ('Acme Corp' vs 'Acme Corporation'), abbreviations ('IBM' vs 'International Business Machines'), or typos. Salesforce requires Accounts as parent records before Contacts can link via AccountId. FlitStack runs a company-name normalization step during extraction — fuzzy matching on company strings — to deduplicate likely duplicates before creating Account records. Unresolved duplicates are surfaced for your team to confirm, preventing a scenario where the same company spawns 3–5 separate Salesforce Account records.

BlinQ's three tag types (contact, workspace, campaign) require separate Salesforce custom fields

BlinQ maintains three distinct tag namespaces per contact: contact tags (applied directly to a card), workspace tags (applied to all cards in a BlinQ workspace), and campaign tags (assigned via BlinQ campaign events). Salesforce has no native multi-namespace tag or label system at the object level. FlitStack creates three separate custom text fields on the Contact object — Blinq_Contact_Tags__c, Blinq_Workspace_Tags__c, and Blinq_Campaign_Tags__c — and populates them with semicolon-delimited tag lists from each namespace. This preserves the full BlinQ tagging context in Salesforce without conflating the three types, which would degrade reporting clarity on which tags came from which source.

BlinQ meeting timestamps map to Salesforce Events but carry no duration data

BlinQ records a single meeting datetime when a contact shares their card via a meeting scan, but it does not store an explicit end time or meeting duration. Salesforce Events require both StartDateTime and EndDateTime. FlitStack sets Event.StartDateTime from the BlinQ timestamp and defaults EndDateTime to StartDateTime plus 60 minutes as a sensible estimate. If your team relied on exact meeting durations for billing or time-tracking, those durations are not available in the BlinQ data export and cannot be reconstructed. You should validate whether Salesforce Events with estimated durations meet your reporting needs before the migration runs.

Salesforce API rate limits apply during high-volume migration loads

Salesforce enforces a daily API request limit (100,000 requests per 24-hour period for Enterprise Edition, increasing with additional user licenses) and concurrent request limits. BlinQ contact exports for large teams (50,000+ contacts) can trigger rate limit errors if loaded via standard REST API calls without bulk processing. FlitStack uses Salesforce Bulk API 2.0 for datasets exceeding 10,000 records, which processes in batches and is governed by separate Bulk API limits (15,000 batches per day, 10,000 records per batch). The migration plan includes a rate-limit monitoring step that pauses and retries with exponential backoff if the org approaches its daily API ceiling, preventing a failed migration run that would require re-execution.