Is there a way to mass convert leads into accounts and contacts using data loader?
I have 2400 leads which are already present in SFDC.
don't want to use code.
[SalesForce] way to mass convert leads into accounts and contacts using data loader
Is there a way to mass convert leads into accounts and contacts using data loader?
[SalesForce] Skipping Leads Entirely – Creating Accounts/Contacts (or PersonAccounts) Directly – B2C
Leads have specific uses: queues, lead assignment rules, auto response rules, web-to-lead, "unread by owner" field, campaign integration, and reporting.
Let's go over each feature in more detail, shall we?
Queues let groups of people pick from a common pool of leads they want to follow up on. Very few organizations use this feature as it is, I believe, instead deciding to use assignment rules for specific types of leads.
Great if you want to get the right leads to the right people, either by territory, product interests, or whatever else you might consider. This is probably one of the most attractive features of leads (besides web to lead and campaign management), although you can emulate this with territory management or workflow rules.
Great way to let your leads know that you've accepted their request. People like to know that. Workflow rules can emulate this on contacts/person accounts.
Web To Lead
Love it or hate it, it's an easy way to put up a form for accepting leads. I'd say that more "mature" organizations have already moved past this very limited feature anyways, but if you're not there yet, you might hold off.
"Unread By Owner"
This feature lets you run reports on who hasn't followed up on leads. There is nothing like it anywhere else in the system, and it's pretty useful to have. It is technically feasible to build this for contacts, though, with some Apex Code, Visualforce, and Workflow rules and/or scheduled Apex Code.
Campaign integration is, among other things, a pretty awesome feature. Unlike contacts, you can import new leads and associate them to the campaign at the same time. When you convert the leads to opportunities, you automatically get ROI reports with no extra effort. You can mass email those leads by campaign. You can make list views by campaign to see which leads are where. Conversion percentages give you the effectiveness of your campaign efforts. In short, campaigns and leads work well together, and you'd be amiss to throw this away without a second thought.
ROI reports. Conversion reports. Market segment reports. Email Campaign reports. Reports. I'm not saying that you can't get at this data without leads, I'm just saying that you're discarding a bunch of out of the box functionality if you do. Now you've got to remember to associate the contact to the campaign. And the opportunity has to be associated, separately. Plus, you don't know how long they were waiting from the time you learned about them until they were converted to opportunities. All of these juicy details are there for the taking.
I understand that many organizations hate the leads feature. I worked with technical support for four years, and I've worked as a consultant for five. Here's the problem with leads: they require, at minimum, more effort to get started, more effort to get configured, and quite a bit of effort to realize the full benefit of leads. This leads to questions like the one presented here: "How can we get rid of leads?", "How can we avoid duplicates?", "What is even the purpose of leads?". The question here shows that you're already at the tipping point; users aren't converting leads, aren't taking the time to "de-duplicate" leads, and aren't using them properly. Leads, in short, are the least understood feature of the entire system, and until you grasp their true value, you can't appreciate them.
Let's take a look at each "benefit" you mentioned.
No more conversion of records
... and no more awesome reports about how your conversions are driving sales, your ROI for campaigns, and everything else.
No more dupe checking across two objects
A lead and a contact in the same organization are not duplicates. A lead is a potential you want to follow up on. Here's the deal: You call the lead, you ask them if they're interested, and you convert them if they show any interest. The system does a pretty good job of de-duplicating leads into existing contacts automatically, except for those fringe cases like "Rob" versus "Robby" and "Bill" instead of "William." But, odds are, you might still end up with duplicates. They're not that hard to merge. Honest.
Master-Slave object relationship possible for objects that were previously required to be accessible from both the Lead AND the Account (Rollups, etc)
Right. The problem is, while leads provide great amounts of information, they are transient. If your leads are older than a week, you're doing something wrong. Nobody in their right mind is saying that you should have a custom object with a "lead qualification questionnaire" that must then be converted to the contact. That's absolutely insane. Additional triggers, additional lookups, and so on. But if you have to ask/state this question/benefit, you are trying to abuse leads, and that's why you want to get rid of them, because you don't understand the feature.
Once initial reprogramming of PHP and Apex is done, much less ongoing programming (only one Object to deal with)
Person Accounts are still two records, and you still have to be cognizant of them as quasi-independent objects. Instead, let your PHP deal strictly with leads if it is lead-oriented, or contacts/accounts if it is account/contact oriented. It is incredibly rare that you would have a solution that absolutely requires you deal with leads, contacts, and accounts in a single PHP script. If you're de-duplicating across lead/contacts, you're doing it wrong.
Nobody's making you use leads, and it's your CRM to do with as you please. However, simply saying that you refuse to use leads because they are worthless instead of trying to work in harmony with them is like preferring a lawyer over marriage counseling. I completely agree that using leads is something that has to grow on you. It's an effort. But I believe you'll be pleased with the results if you give it an honest try.
The two most highly rated free de-duping Apps on the App Exchange are Dupe Catcher and Duplicate Check. Some of the features in the latter are available only in the paid version while everything in Dupe Catcher is completely free.
As part of full disclosure, I'm not financially associated with either company but have met some of the employees of Symphonic Source (makers of Dupe Catcher) as they're local to me. They've presented at the Dallas Developer's User Group on their Cloudingo Studio and likely attend at least some of our meetings. As we now have over 400 members it would be difficult for me to say.
As for "best practices", I think that's a difficult one to answer. Some companies like to merge duplicates while others will archive duplicate contacts and delete duplicate leads. When it comes to leads, which to do might depend on the source of the lead, how complete the info is on one vs another or how highly the one lead was ranked from one source vs the from another source as to what you'd want to do. I'd think you'd need to establish your own criteria, including any differentiation due to product interest, etc. as to how or whether to merge them. I don't think there's a simple answer considering that the process of generating and handling leads can be rather complex in many organizations.
One situation that can come up is where a duplicate contact name gets identified where a contact of the same name is is now with a different company. That's obviously a situation that needs to be handled carefully. Do you archive the contact ID for the name of the person at the previous company they were with or do you merge it with the contact ID where the same person is at a their new position in a different company? As an Account related contact ID, are there Opportunity or other records that need the old contact ID as a reference which might prevent it from being merged if related to a new account? If not, I think that's a decision an Org needs to make for itself. There's another app called Former Positions that might be helpful if you want to keep track of a contact as they move from company to company without losing that history. Again, I think that's a decision an org needs to make based on their particular needs for information and not necessarily one of what's a general best practice.
I hope this response is helpful to you.
Dataloader only supports basic DML operation, you cannot use it to convert to leads as it requires additional information while conversion and convert lead operation is not supported by dataloader.
You can maybe write a batch apex with
Database.convertLeador try some appexchange package.