Many a times, we come across business use cases that force us to introduce apex customization which obviously comes at a heavy cost. To keep the maintenance costs low and for quick results, the declarative capabilities of the Force.com platform is simply amazing ! However, the declarative capabilities in itself has its own limitations. So, today I will walk you through a use case which is actually relevant for many customers and what’s the best way to implement it which would otherwise require some customization in apex.

Business Case: ABC company uses Accounts and Contacts and they have many contacts associated with an Account. However, for communication purposes they want to identify a primary contact for each Account which will then be their single POC for all the communication purposes. To implement this, they want to ensure that only one contact is selected as a primary contact for each Account at a time.

Implementation: Validation rules ! Yes, indeed they are the first thing that comes into our mind when we want to restrict something. However, is this scenario only possible through a validation rule. How do you check if there are other records with a primary flag selected ? Yes, you could have done that had this been a custom object by using VLOOKUP. However, standard objects don’t support VLOOKUP. So, we will be shaking hands with a workflow rule to build this validation rule.

What we will be doing ? : We would create a custom text field named as “AccountID__c” in Contact and make it a unique field and populate that field with the Account ID every time a contact is selected as primary. So we will create a workflow rule to check if the contact has been selected as a primary contact and then do a field update on the custom field. Pretty Straightforward !

So now if a contact is selected as primary, the custom text field  in my case “AccountID__c” would immediately be populated with the Account ID. Again, if we try to select another contact as primary within the same Account, the workflow field update will throw an error saying that “Error: Duplicate value on record”

 

Step 1

s1

 

Step 2

s3

 

Isn’t it interesting that you could actually build a validation rule by being a bit tricky with the workflow rule ?

So, the next time you have a requirement, take a look if there is any possible way to do that with the declarative capabilities. You should probably step into customization only after you are dead sure that it cannot be done with declarative capability !

Remember that you will need to have additional setup if you decide to some day change your primary contact from one contact to another. I would leave that to you to figure it out yourselves. If you have any questions please feel free to comment on this post.

Happy using Workflow rules !