There are now only a matter of hours to go until Salesforce’s Winter ’15 release begins to hit production servers. This release bring a lot of great features, many of which were covered by Mike in his earlier release notes highlights post. In this blog, I want to turn the spotlight on the feature I’m most excited about, because nearly all orgs could benefit from using it: Duplicate Management.
Despite being one of the stand-outs in the release notes, this feature isn’t even Generally Available yet (that’s slated for Spring ’15 – Safe Harbor) but it has moved from pilot to beta. That means it’s well on the way to becoming a reality, and that is excellent news to the 6,500+ people who have voted on this idea – the second most popular on the entire IdeaExchange.
Like South Park’s Mr Mackey above, I think we can all agree that duplicates are bad. There are a number of reasons for this: they hamper the user experience (Which record do I use?), they harm the accuracy of reporting (How many customers and contacts do we really have?), they complicate marketing automation integrations (Which record should have its score increased?) and they make it all but impossible to integrate with systems that already have duplicate prevention embedded (Which record should be matched?).
Yet many orgs have no duplicate prevention measures, perhaps because they don’t have the budget, or because free tools don’t cut it for them, or because they don’t know how to implement these tools. It could even be the case that creating duplicates is done deliberately as a short term fix to satisfy an immediate analytics need. But mostly it’s because they simply don’t know they have a problem with duplicates yet.
So having a solution baked right in to the platform is good news for all. Hence I wanted to spend some time analysing what benefits the feature will bring, what limitations it will have, and whether we can clear up some of the unanswered questions around the launch (while maybe even asking a few of our own)…
How will it work and what will it do?
The aim of the feature is straightforward: it will allow you to control whether and when your users are allowed to create duplicate records. To do that, you’ll customise the logic around what counts as a duplicate and what to do when a possible duplicate is found.
Once the feature is enabled, you will create both a matching rule, a set of criteria used to compare records and detect potential dupes, and a duplicate rule, instructions around what to do when a duplicate is found (your options are essentially to block the save or to alert the user but allow them to save – both will display a message explaining the situation to your users).
Here’s how the alert looks in Salesforce1, and in the interests of saving mobile users time the alert will appear once the user exits the triggering field rather than waiting for them to have populated the whole record and then firing only on save.
Your duplicate rules can also use conditional filters so that, for example, system administrators are exempt or so records with a Company/Account Name of ‘Unknown’ can pass through. In addition, you can choose whether to enforce or bypass sharing rules: if you bypass them, even records that the user cannot view can be matched as a duplicate (the block or the alert will still occur, but the protected records won’t be displayed to the user).
What are the feature’s limitations?
In Winter ’15, the Duplicate Management feature is being release as a beta, which means it is of production quality but with known limitations – we list some of the most important ones below. What is unclear whether there is any intention to fix some of these gotchas prior to the feature going GA.
– Only available for accounts, contacts and leads. Custom objects* and person accounts are not supported.
– Does not work across objects, so you can’t check for pre-existing contacts when entering a lead.*
– Duplicate rules will work in the way you configure them for records created from their tabs or edited via the full edit mode or inline editing. Other methods of creating records, like lead conversion, Chatter publisher or data import tools will always block saves regardless of the choices and conditions set out in your duplicate rules.
– The dreaded Quick Create function bypasses all duplicate checks. Just one more reason to turn it off if you haven’t already done so!
– Fuzzy matching rules work best on Latin characters; international data is only recommended for use with exact match rules.
What does this mean for ISVs in the duplicate management space?
A number of AppExchange partners provide these types of solutions already: some are free and some are paid. So does this free, native feature pose them a risk?
The immediate reaction has to be yes: on the surface this does much of what those third party tools do, for free. But look closer and consider the above limitations – especially the lack of cross-object checking. The specialist providers have mature products that give them quite a head start.
There is no doubt that as the feature develops and as each limitation goes away, it will pose a bigger threat to some AppExchange partners. But these companies have some good brains behind them and my guess is that this will spur them on to innovate more and move further ahead. Keep ’em peeled: whichever way it goes, it’s going to be interesting.
What does the Data.com branding of the feature mean?
Full name of feature is ‘Data.com Duplicate Management’. Before full details were known there was some talk that the product would only be available to Data.com subscribers. Thankfully this has now been disproved: the feature will be available to all ‘real’ editions and will be free. The Data.com label is really just there is show that this feature set belongs firmly in the Data Management Cloud, which for Salesforce is Data.com.
However, there is a strong suggestion that in the future the feature will be extended to include an automated tool to help clean existing duplicates outside of user entry, and it has been indicated that this add-on may be reserved for paying Data.com customers.
It’s clear that the functionality that will be delivered, when combined with the huge challenge that duplicate prevention poses for almost every Salesforce customer, means this has the potential to be a huge addition to the product. It will give a lot of customers an easier, native way to get a handle on a serious issue that has far reaching implications for critical business processes.
The free nature of the feature will push existing AppExchange vendors to innovate, though it has clear limitations in its first iteration that won’t have them too scared just yet. But as each challenge is cleared (as it surely will be, given the popularity of this idea in the community) the product gets better, fuller and more usable.
So if your org has an issue with duplicates, or even if you think it might (and don’t bury your head in the sand on this: virtually every single org will have some degree of challenge around duplicates), give Duplicate Management a go as soon as you are able. Get using it, push its boundaries and feed back your experience and suggestions to the community. If enough of us do that, we’ll help Salesforce overcome the limitations of the beta product more quickly and when that’s done, this will be a fabulous addition to the platform.
A version of this article was delivered in a recent presentation at Awesome Admins, the new London user group for UK Salesforce Administrators. If you haven’t signed up for the meetup yet, do so now. *UPDATE 07/10/14: News is developing fast around this much-anticipated new feature and we can now share the following: – Salesforce PM Dan Milbrath confirms support for cross-object checking is targeted, Safe Harbor, for introduction in Spring ’15 when the product goes GA. – A FAQ document has been published to the Success Community which confirms support for custom objects should also be available in the GA release. Thanks to Jacinta Burke for the heads-up on that. – Two video guides are now available giving detailed walkthroughs on setting up matching rules and duplicate rules.