Enforcing Unique Constraints in Salesforce with Apex

In Salesforce, we often come across scenarios where we need to enforce unique constraints on certain fields of an object. What if we need to enforce a unique constraint on a combination of fields? This is where Apex comes in.

The Problem

Let's consider a real-life example in an organization that sells software licenses. The organization has a business rule that for a given Quote, there should not be more than one QuoteLineItem with the same Product and LicenseType (a custom field representing the type of software license). This is to prevent sales reps from creating duplicate line items for the same product with the same license type in a quote.

The UniqueConstraintValidator class can be used to enforce this business rule. When a sales rep tries to create or update a QuoteLineItem, the UniqueConstraintValidator checks if there is another QuoteLineItem with the same Product and LicenseType for the same Quote. If there is, it prevents the record from being saved and displays an error message.

However, Salesforce does not provide a way to enforce this complex unique constraint that involves multiple fields (Product2Id, LicenseType__c, and QuoteId) out of the box.

The Solution

To solve this problem, we can use Apex to write a class that enforces this unique constraint. The UniqueConstraintValidator class does exactly that. It accepts a list of records and checks if there are any duplicate records based on the fields specified in the constructor.

Here is how you can use this class:

trigger QuoteLineItemTrigger on QuoteLineItem(before insert, before update) {
    UniqueConstraintValidator validator = new UniqueConstraintValidator(
        'QuoteLineItem',
        new List<String>{ 'Product2Id', 'LicenseType__c', 'QuoteId' }
    );
    validator.validateUniqueConstraint(Trigger.new);
}

In the above code, we first create an instance of UniqueConstraintValidator, specifying the SObjectType and the fields that should be unique. Then, we call the validateUniqueConstraint() method, passing in the records that we want to validate.

You can find the complete code for the UniqueConstraintValidator class in this github gist link.

Limitations and Improvements

While the UniqueConstraintValidator class provides a flexible and powerful way to enforce unique constraints, it has some limitations. For example, it does not validate that the object and field names provided to the constructor actually exist in the Salesforce schema. This could lead to runtime errors if invalid names are provided. To improve this, we could add validation logic in the constructor to check that the object and field names exist. This would prevent invalid names from being used and provide a more informative error message if they are.

One of the main limitations is that it can only use string or Id fields as unique constraint fields. Another limitation is that all the unique constraint fields should have a value. If any of the fields is null, it could lead to incorrect results. To handle this, we could modify the getCombinationString() method to skip null values.

Another potential improvement is to leverage custom metadata to make the class more maintainable. Instead of hardcoding the object and field names in the code, we could store them in custom metadata. This would allow us to easily change the unique constraints without modifying the code. In the current implementation, if we need to change the unique fields for an object or add a new object with its unique fields, we would need to modify the Apex code. This is not ideal as it requires code changes and deployment to production. By leveraging custom metadata, we can store the object and field names in a custom metadata type. The UniqueConstraintValidator class can then retrieve this information at runtime. This way, if we need to change the unique fields for an object or add a new object with its unique fields, we can simply update the custom metadata without any code changes.

For better performance, we can add a condition to validate only when one of the values for the unique constraint fields has been changed. This can be achieved by comparing the old and new values of the fields in the trigger context.

Before enabling this functionality, make sure that the existing data is already cleaned. This could involve merging duplicates, updating the fields to make them unique, or deleting unnecessary records. If there are existing duplicate records, they will cause errors when the unique constraint is enforced.

An Alternative Approach: Using a Unique Custom Field

While the UniqueConstraintValidator class is a powerful tool, there is an alternative approach that can be used to enforce unique constraints. This approach involves creating a custom field that concatenates the combination of unique constraint fields, populating data in this field either using a trigger or a record-triggered flow, and then marking the custom field as unique. While this approach of using a custom field can be a viable solution, there are several reasons why it's better to use the UniqueConstraintValidator class:

1. Custom Error Messages: The UniqueConstraintValidator class allows for custom error messages. This can provide a better user experience as the error messages can be tailored to the specific use case. With the custom field approach, Salesforce generates a standard error message which may not be as informative or user-friendly.
2. No Additional Fields Required: The UniqueConstraintValidator class does not require the creation of additional fields on the Salesforce object.
3. Code Reusability: The UniqueConstraintValidator class can be reused across different objects and fields. This can lead to a cleaner and more maintainable codebase.

Conclusion

The UniqueConstraintValidator class provides a flexible and powerful way to enforce unique constraints on any Salesforce object and any set of fields. It can be used in a trigger or any other Apex code to validate unique constraints and add errors to duplicate records. This helps ensure data integrity and prevent duplicate data in Salesforce. With some additional validation and the use of custom metadata, it can be made even more robust and maintainable.