Thursday, December 22, 2016

Quick Tips: Some things about Salesforce Validation rules you may not know

What are validation rules?

While creating any application, one of the most crucial building block is clean and good data. We do get ability to define required fields on field and page layout level, but there can be complex scenarios where the business rule needs multiple fields to ascertain data quality. 

Salesforce provides a very helpful feature called "Validation rule" to ensure administrators/ developers can create custom validation rules on Salesforce objects. These validation rules help ensure that any record being created or updated qualifies to defined business rules. If not, then developers/ administrators can display required error message.

Validation rule constitutes of:-
  • Formula - formula to evaluate business rule. If formula evaluates to TRUE, validation error is thrown, else it's considered as validation success
  • Error message - error message to be displayed on validation failure
  • Location - Enables admin/ developer to define location to display validation error. In standard page layouts, it'll allow user to show error either at page top or beneath the selected field

Validation rules are invoked anytime a record is created/ updated via any process I.e. manually from UI, API etc.


When to use validation rules?

Validation rules are most useful to implement required business rules without using any code. All validation rules are configurable and can be modified/ disabled by admin/ developers whenever needed.

There can be many scenarios where business rules are to be defined, so that user gets appropriate data validation error messages. For example

  • A user cannot create a contact without email address where the contact's preferred contact method is Email
  • A user cannot assign case back to Queue

To know more about how to create validation rules refer help article 
Define Validation Rules
Examples of Validation Rules


When validation rules may not be applicable?

However, there can be scenarios wherein the business rule needs multiple records or child records to assess data validation. In such scenario, Apex triggers will be best avenue to implement business rules.

Scenarios where Validation rules are skipped


  1. If validation rules exist for activities and you create an activity during lead conversion, the lead converts but a task isn’t created
  2. Campaign hierarchies ignore validation rules
  3. If records are mass assigned via Mass Transfer tool, Change owner and Accept buttons
  4. During lead conversion validation rules are skipped if validation and triggers for lead conversion are not enabled
  5. When changing ownership on Accounts, Opportunity Validation Rules are also ignored when selecting to transfer Closed Opportunities and Opportunities not owned by the existing Account Owner
  6. If workflow rules and process scheduled actions modify the record, validation rules are skipped

Considerations


  1. Because updates to records based on workflow rules and also on process scheduled actions don’t trigger validation rules, workflow rules and some processes can invalidate previously valid fields
  2. Salesforce runs validation rules before creating a record via web to lead or web to case, if the any rule fails, the record is not created
  3. Validation rules apply to all fields of the record, irrespective of any page layout; that is, 


For more details refer:-

https://help.salesforce.com/articleView?id=fields_validation_considerations.htm&type=0&language=en_US&release=204.17

https://help.salesforce.com/articleView?id=000005079&type=1&language=en_US

Thursday, April 28, 2016

New Salesforce Book - Apex Design Patterns


 

I'm really excited to share that today my book (co-written with Jitendra Zaa) has been published. Here are some personal insights

A little history
This particular topic was always in my head and coming from .Net background and having worked with lots of design patterns in MS development world. I first successfully used Factory design pattern with Apex in 2009, when all my team was scratching their head and (cursing me badly) for "overtly complicating" the code architecture. They were happy with creating 20-30 different VF pages, which I emphasized needs to be designed with the help of 4-5 VF pages, VF components and factory method pattern. Well, we were able to complete the whole stuff in time and deliver it flawlessly. It was then and similar instances later that I realized that a larger faction of Salesforce developers (back then) had very less knowledge about design patterns and code architecture. There was a huge gap.

Over the years a lot of bloggers have shared so much valuable content that the gap has almost diminished now. It was during conversation between Jitendra and myself that we realized that we should address this area and try to share some more details.

About the Book (also included in book)
The first and obvious challenge we faced was the presence of lots of highly informative and relevant blogs and books out there addressing design patterns. Largely, the information is out there. But, we realized that most of the content is primarily Java centric and it is very hard for a non-seasoned Java programmer to understand the nomenclature of design patterns. Furthermore, most of the example scenarios are also very alien to Salesforce development.

So, we created content keeping Salesforce developers in mind. The content was supposed to be very easy to understand and the all scenarios were to be Salesforce related. We spent so many hours debating on minute things, to ensure that any reader reading this book will be able to grasp and hold on to the knowledge (it's the latter part which has been the biggest challenge with design patterns).

Writing Experience
Well, all I can say is that it was not easy. All these months (around 7-8) we were in constant pressure to stick to timelines. So, we divided some patterns amongst ourselves. Then came Dreamforce '15 and we got really occupied with it. After Dreamforce '15, we completed first draft of all chapters and shared. All this while we both were working in silos and interacting on need basis.

BAAM!! came the review, and let's just say it was not that bad (as I expected) and not that good either (I very well expected that). So, we sat down together and realized that we got to dedicate lot of quality time together on this, if we have to deliver this. So, we did. We spent lots of nights and weekends on phone calls (2-7 hrs in a day) and reviewed each and every sentence. It'll not be wrong to say that we almost re-wrote entire content again.

Lastly
At the end it was definitely a very tough journey. But, as they say "No Pain, No Gain". However, painful it was to write and review content at 3AM in morning, it given immense satisfaction to learn that I was able to contribute towards greater purpose of sharing knowledge amongst community.

Sincere thanks to Jitendra(co-author) for his dedication and support. Thanks to John(reviewer) for his impeccable reviews. I'm sure he would have recovered well after reviewing our first draft (pun intended).

I really hope that every reader will be able to understand and adapt to the usage of more and more design patterns or rather structured code architecture. Feel free to share your comments with Jitendra and myself.

Popular Posts