Migrate from BlinQ to Microsoft Dynamics 365 Sales

Each Blinq contact card maps to one Dynamics 365 Sales Contact record. The primary AccountId is resolved by matching the Blinq company field to a Dynamics Account by name — if no match exists, a placeholder Account is created. The Blinq card owner's own card maps to a Contact representing the user in Dynamics (for activity attribution).

Blinq stores a single company text string per contact. We deduplicate unique company values across all Blinq contacts and create one Dynamics Account per unique company name. Contacts without a company value link to a default 'Individual / Unassigned' Account. Parent-child company hierarchies in Blinq are not modeled and require post-migration manual structuring in Dynamics.

Blinq tags are free-form string values per contact with no predefined taxonomy. We collect all unique tag values, create a Dynamics OptionSet with those values, and map each contact's tag set to the custom field. Contacts with multiple tags store the primary tag as the OptionSet value; secondary tags are appended to a secondary text field Blinq_SecondaryTags__c.

Blinq meeting records include title, date, and context notes. We split by title keyword: entries containing 'call', 'phone', or a phone number pattern map to Dynamics PhoneCall activities; entries containing 'meeting', 'event', or a calendar-style title map to Appointment activities; all others map to Task. Each Activity record gets regardingobjectid pointing to the Contact and CreatedOn set from Blinq's meeting timestamp.

Blinq stores AI-generated conversation summaries as plain text per contact. We create a Dynamics Annotation (Note) linked to the Contact with the note body as Body text, plus a copy in the custom text field Blinq_ConversationNotes__c for inline visibility on the Contact form. Original creation timestamp from Blinq is preserved in CreatedOn.

Blinq allows per-card profile custom fields (e.g., 'Referral Source', 'Event Name'). Each unique custom field label generates a corresponding custom column in Dynamics Dataverse on the Contact table. Field types are inferred from Blinq value patterns: date strings → Date fields, numeric strings → Number fields, URL strings → URL fields, free text → Text. We create the field definitions before migration data loads.

Blinq appends third-party enrichment to contacts (company headcount, industry code, LinkedIn profile URL). We map these to custom fields on the resolved Dynamics Account: Blinq_CompanySize__c (Number), Blinq_Industry__c (OptionSet), Blinq_LinkedIn__c (URL). If no Account exists yet, enrichment fields are stored temporarily on the Contact and reconciled when the Account is created during migration.

Blinq tracks how many times a contact's card was viewed or shared. This metric has no native Dynamics equivalent — we preserve it as a custom integer field Blinq_ShareCount__c on the Contact record for post-migration reporting continuity. Share timestamps are not exposed in the Blinq API and cannot be individually migrated.

Blinq card creators map to Dynamics 365 Sales users. We match Blinq owner email addresses against Dynamics SystemUser primaryemail. Unmatched owners are flagged before migration — teams either pre-provision the user in Dynamics or assign their contacts to a fallback owner. Activity records use the matched OwningUser to preserve attribution.

Blinq does not store deal records, pipeline stages, or opportunity amounts. If your team used Blinq tags to informally track deal status (e.g., 'Hot Lead', 'Closed Won'), those tags can be mapped to a Blinq_LeadStatus__c custom field on the Contact — but no Opportunity record exists in Blinq to create in Dynamics. Sales process and pipeline design must be built fresh in Dynamics 365 Sales post-migration.