2

When the number of records in the database increase, logically there must be decrease in performance. This degradation can be explicitly observed in SOQL/list view/reports on such orgs especially those that return large number of records( not selective enough).

How does the performance of inbuilt features like "Duplicate Management", "Unique Field" etc fare in the face of large data in the database. Will they be degraded in the same way - custom code performance is?

In a specific scenario, I have implemented duplicate management using apex code - should I switch it to using standard duplicate management - does this help in the situation that I have large data volume in my org?

PS: The reason as to why I implemented duplicate management using code and not out of the box is because, it was not straight forward and used multiple lookup fields on the matching logic.

Thanks in advance.

2

The programmatic features of the Force.com platform make it easy to customize functionality, but always use standard objects and declarative features whenever possible. Standard objects and declarative features—such as approval processes, visual flows, workflows, duplicate management —are highly optimized already and don’t count against most governor limits.

Salesforce mentions 3 reasons as to why we should go with declarative features rather than code. I consider these 3 points and answer for your Duplicate Management VS Code.

Cost and time – using declarative development features is fast! It doesn’t involve writing code, writing test classes, worrying about checking in code into a repository, version control your code, etc.

This is 50-50 to Declarative duplicate management VS Code. If your scenarios are simple, the time taken to code would be same as that to setup the duplicate management declaratively.

Maintenance – probably one of the biggest differences. There is no code and test automation needs to be maintained when using native features and declarative customizations

This is another big advantage with duplicate management. No test classes, no governor limits if data increases. Nothing at all. Salesforce takes care.

Complexity and Scalability – we can still build a lot of complex things without writing a single line of code, but there is less to worry about in terms of governor limits as they don’t apply to declarative customization. There are of course limits to keep in mind for declarative customizations as well, but the main difference is that these are design limits (e.g. total number of workflow rules on an object) rather than execution governor limits (e.g. total number of SOQL queries issued), so they’re easier to handle with a thoughtful design approach.

For de-duplication, there are lots of limitations to go with Declarative duplicate management. Like it doesn't support- converted leads, person accounts etc. That's one of the reasons we are still doing duplicate management by code!

Finally, if your requirements/scenarios are all supported by standard Duplicate management, then YES you must use declarative than code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.