New Matching Types in DemandTools 1.7
Friday, July 14, 2006
We are always looking for new ways to match up duplicates with out new Single Table Deduper and have recently added Address Match, Relaxed Address Match and Relaxed Phone Match. These types of matches work great on your later dupe stages when you have already found the duplicate objects (Accounts, Contacts, Leads, etc) that have similar names but you now need to find the tough ones where the Account name has changed or is so badly misspelled that you will never match it.
Here is how they work:
Relaxed NA Phone Match
If the phone number is sales force was one of:
+1 (416) 628 1486
416 628 1486
415 628 1486
628 1486
It would be reduced to 6281486 and all of the above numbers would match.
Address Match
If your input address was one of:
123 Main Street North, Unit 23
123 Main St. N – Unit23
123 Main st N Unit 23
The Address Match output would be:
123 Main St N Unit 23 - all of the above addresses would match
For a Relaxed Address Match the output would be 123 Main
As you can see the Address Match will “Normalize” the address into a common form and the Relaxed Address Match will return just the street number and street name ignoring the type (street, ave, blvd) or any other information.
The result of this matching is that you could find some very tough matches where there has been a phone area code change and the address was entered in a non-standard fashion. For example, the following would be a match if you just used Relaxed Address and Phone matching:
Bob’s Custom Boats
123 Main Street North, Unit 234
416 628 1486
Robert Smith and Sons Yachts
123 Main St, Suite 234
(905) 628 1486 x234
posted by Glenn Wilson @ 9:35 AM,
Bug Fixes in 7.0 API - Quick Find
Thursday, July 13, 2006
I always forget what SFDC has fixed from the API bug sheet, here is the fixes in the 7.0 release of API
- Querying the name field on profile works correctly in the 7.0 API. Prior to 7.0, the names came back as PT1, PT2, etc. (Note: The behavior for API versions 6.0 and lower will not change.)
- Previously, queries against Task did not match the results received from reports on Task delivered via the application. These behaviors now match.
- SOQL filters (greater than, less than) on negative numbers now work. Previously, a query such as: "Select Id, Name, AccountNumber from Account where ofITStaff__c > -1" would return an error.
- Previously, a number of objects allowed the owner to be changed to an inactive user. The API will now return an error when an attempt is made to assign a record to an inactive user.
- Assignment rules based on formula fields will now work correctly in all versions of the API.
- getUpdated calls for non-admin users will now evaluate the sharing model prior to returning data. This may result in some objects returning less data than before 7.0.
- When activating a contract with a user-defined Activation value, the picklist value is remembered correctly. Previously, it would always set the value to the "Activated" picklist value.
- SOQL queries that return a formula field with a GETSESSIONID function will return a valid session id.
- The BusinessHours object is now described with a label. Previously, there was no label.
- AccountShare has a field called AccountAccessLevel. The "Private" option has been removed from this enumeration, as it was never a valid option.
- The defaultedOnCreate flag is now set to true on AccountShare.AccountAccessLevel and AccountShare.OpportunityAccessLevel. The behavior does not change, however, the metadata will be described correctly.
- The pluralLabel on CaseComments was changed from "Case Comment" to "Case Comments".
- The label and pluralLabel on CaseShare.CaseShare are changing from "Opportunity Share Default" to "Case Share".
- The label on LeadShare.LeadAccessLevel is changing from "Case Access" to "Lead Access".
- Error behavior for deleting a non-existent ID has changed in version 7.0. Attempting to delete a ID will now return INVALID_CROSS_REFERENCE_KEY. The behavior in 6.0 and below has not changed, deleting non-existent IDs will return success.
posted by Mark Esdale @ 9:52 AM,
