Apex Code Development You need to sign in to do that
Don't have an account?
GlennW Testing assistance needed
If anyone out there has a large salesforce.com account with a few duplicate accounts it would be great if you could test out my account de-duper. The current beta version does not do any merging of the accounts, contacts, oppertunities yet but the first 2 steps do work and they will show you all of the duplicate account names in your setup and will allow you to export those duplicate names to a CSV file.
The idea of the tool is that it uses a "Replace List" to clean account names by replacing things like "&" and "+" with "and" and will trim off known suffixes like "Inc." You can even force a more unique search by including the billing city or any other custome salesforce.com account field. This way I.B.M. Inc. in New York will not match IBM Corp in Chicago, but, if the city was not used they would match.
You can grab the setup from the URL below and you will need the .NET framework installed in order for it to run.
Here is a screen grab of the first and second page. You can force master accounts on the second page by just right clicking on the account name.
I'll be dropping up some sample code later on to show you how to convert the return from the sforce webservice account query directally into a .NET datasource. It's only a couple of lines of code but I'm sure that you'll find it usefull in building complex application.
If you have any comments feel free to email me at glenn.wilson@demandtools.com
Cheers;
Glenn Wilson
Message Edited by GlennW on 04-27-2004 06:30 PM
Glenn-
Very cool stuff! I have tried using this, but when I go to login, it throws an error saying that it cannot find "c:\projects\salesforce\account.xml". The install did not create any such directory structure, is that something I need to do?
Thanks!
Sean
Oooops......
Forgot to take out some debugging statements. I've updated the link with the new setup. But, as you already have the install loaded you can just replace the exe found here: http://dev.quotegen.com/fm/sfdedupebetaexeonly.zip
Cheers;
GlennW
Works like a champ Glenn, thanks! One addition that I would recommend is adding Account Site as a standard "Criteria for finding duplicate accounts". Salesforce.com recommends a best practice that has customers using that field to identify different locations (plants, etc.) of the same account. We also use it in our own de-duplication procedures on imports and Lead conversions.
Thank you for putting this together and please keep the list posted on your progress. Based on existing customer feedback, this will be a very useful tool!
Sean
Sean;
Good to here. I'll add in site and maybe replace phone in the checkbox fields but I'll still allow for one "custom" field that they can include in the dupe key. My experiance as a user of saleforce is just about incompetant so I'd like to get a chance to talk with someone who can fill me in on how account, contacts, oppertunities, etc should be merged and how ownership should change on the merge.
Cheers;
GlennW
I get a login error with the app. Could this be because the account is a trial account? It *is* configured as an Enterprise account tho, so I'm surprised it doesn't work. I successfully connected to my dev account, but the data I want to check for dupes is in the trial account.
Ollie
I don't think that trial enterprise accounts are API enabled. You'll have to talk to one of the salesforce.com folks and have it enabled to test out. I haven't put the merging into the application yet for the salesforce build but the tool will find your dupes and let you dump out a csv of the results.
Cheers;
GlennW
To have a list would be a good starting point I think. Is your intention to do the actual merging? We've enough duplicates that dealing with them by hand is a pretty arduous process, so we'd be looking for a way to automate it.
I'll see if I can get our trial account API enabled so I can get the CSV.
Thanks
Ollie
Use your Developer Edition account - the one you get with sforce. This version is based on Enterprise Edition and (obviously) has the API enabled.
Trial versions of salesforce.com are Professional Edition - which does not provide API access.
--
Mike
My trial account is Enterprise, not Professional. However it does not allow API access.
I would use the developer account I have, but I have put a lot of time into getting the data into the other account. I would prefer not to go through that process again.
I've raised a case with support to have my trial account enabled. I figure that is possible.
Ollie
Ollie,
Send me your username and I will inspect your org to see what is going on.
Send it to me directly - via email - to mkreaden@sforce.com.
--
Mike
I've got the full merge working under a different CRM system so it's just a matter of porting the object types over to salesforce.com. I'm new to the salesforce model so I've got to figure out the objects that need to be moved and merged.
If you have any recommendations please drop me a line and I'll try to put them in. I've also build a mass update tool (reads xls, csv or mdb) that updates records as long as you export your ID field. If there is a requirement I'll port that over as well.
Cheers;
GlennW
Do you plan on selling the software?
How does your mass update code differ from the functionality in SF that merges new contacts with existing? (based on name and account name as far as I can see)
Ollie
I am currently selling the software but it works on a different CRM system. My plan is to move the deduplication wizard and the mass update tools over to sf and see what the response is.
To use the tool the first step is to export the records that you want to change (just make sure you export the ID field). The data can be modified in excel (or access) and the tool is then used to update the records by reading the data in the xls and modifying each record in sf.
email me at glenn.wilson@quotegen.com if you would like more info.
Cheers;
GlennW
Mike;
How do I allow for access to the eu server in the login? I notice that the server_url is set to "http://na1.salesforce.com/servlet/servlet.SoapApi" and is initialized from the WSDL.
Cheers;
GlennW
Glenn,
If you are creating a commercial app, you should not hard code the server url for API calls. The best practice for establishing a session involves using the single logon server (www.salesforce.com), which will return the user's server_url with which to make subsequent API calls with.
This is documented in the reference manual.
I suggest that you upgrade to use the v2.0 API for your commercial app.
In the meantime, if you change your server_url reference to
https://emea.salesforce.com/servlet/servlet.SoapApi (for secure calls), your calls should work.