Duplicate detection stops treating a shared LinkedIn as the same company

The Duplicates page was grouping records that had nothing in common beyond a social or directory link. Matching on a web address only makes sense for a domain a company actually owns - everyone's page is on linkedin.com, everyone's listing is on the same directory, and plenty of businesses share a website builder's domain - so those were folding dozens of unrelated records into one group. Solstral now recognises social networks, business directories and review sites, site builders and link shorteners, and compares the part of the address that identifies you: linkedin.com/company/acme and linkedin.com/company/globex are correctly different, the same profile written two ways still matches, and a bare twitter.com with no profile on the end is ignored entirely. Regional and mobile variants (au.linkedin.com, m.facebook.com) fold onto the same network instead of looking like separate sites. The same field can also mean two different things depending on where it sits: a website on a company identifies that company, while a company domain on a contact identifies their employer - and forty colleagues sharing it are forty different people. Solstral now works that out from your data rather than asking you to configure it, so a repeated domain on a mostly-unique field is still a duplicate, while a domain that repeats by design only counts when the names agree too. Two records for Jane Doe at acme.com are offered as a duplicate; her colleagues are left alone. Any single address that pulls in an unusually large crowd is treated as a shared platform rather than a duplicate set, which catches directory sites we haven't catalogued yet, and the page now tells you how many records were skipped for these reasons so an empty result doesn't read as a bug. CSV import matching follows exactly the same rules, so an imported row can no longer attach itself to an unrelated record because both happened to list a LinkedIn URL.