Spring Training Episode 2: Salesforce Workflow and Validation Rules

March 6, 2014 John Gorup

baseball mit

Last week we started a blog series about taking time to focus on the fundamentals of Salesforce. We began with adding fields to custom objects, and this week we shift to two of the most widely-used features in Salesforce: Workflow and Validation Rules.  The beauty of these two features is that they give you a powerful way to enforce business rules without writing Apex code.

It’s useful to remember all that Workflow rules do, so that you know when best to use them. To refresh my memory, I reviewed the Workflow section in the Salesforce Handbook by Jeff Douglas and Wes Nolte , where they list the actions for workflow as:

  • Field Updates – Update the value of a field on a record. For example, automatically change the lead’s owner to a queue or another user based upon the value of the lead status.
  • Email Alerts – Send an email to one or more recipients. For example, automatically send an account manager an email notification when a support case closes.
  • Tasks – Assign a new task to a user, role or record owner. For example, automatically assign a follow-up task for the account manager to call and thank a customer one week after the opportunity closes.
  • Outbound Messages – Send a secure, configurable API message (in XML format) to a designated listener. For example, automatically notify an external HR system when a user updates their home phone number.

After reviewing when to use Workflow Rules, I wanted to gather some best practices around using them. Once again I turned to the Appirio All Stars to get some best practices around Workflow, most of which came from Rhonda Ross.

catchersFirst of all, add good descriptions when creating workflow rules and related actions, detailing what it is for and what it does.  A good naming convention is “action and verb”.  For example “Set Stage”, or “action, verb and value.” If the rule only applies to one group, precede with the group name.  One naming convention Jarrod Kingston likes is to add an abbreviation of the object name at the beginning of the Workflow rule name (For example: Opp | Update Stage to Closed Won) to give added context in all areas of Salesforce.

Of course, one of the most difficult decisions when creating a new workflow rule is determining when the workflow rule should fire. Always consider if the rule should apply always, or just to certain record types, profiles.  Ralf Hoffman added: with exceptions, it is usually best to include an OR(isnew(),ischanged(<field(s)>)) condition around workflow rule (or validation rule), to make sure the test is applied to specific instances and that the workflow only triggers when it should.

Another helpful practice is to use custom settings that can act as a master on/off switch for all workflow rules.  This works well for easily turning off rules for data migrations. Jarrod also suggested another trick to control when a workflow (or validation rule) fires on a user-by-user basis by adding a custom checkbox to the user object for Workflow and Validation Rules. If the custom field is checked, then don’t have the workflow or validation rule fire for that user.

A Validation rule in Salesforce is useful for making sure the data in a specific field obeys your pre-defined data integrity rules.  Many of the best practices for Workflow Rules also apply to Validation Rules, such as naming conventions, determining when to fire, and using custom settings.

However, one best practice is to stick to displaying the error message for the Validation Rule next to the relevant field.  Only when multiple fields are checked at once should you place the message at the top of the page.

Another point to remember about Validation Rules is that adding a new Validation Rule can break existing Apex code. This is especially true with test code if you add a required field that the test code fails to populate.

Workflow and Validation rules are two fundamental Salesforce features that are important to master. Sticking to solid standards and practices will pay off in the future, and help your salesforce org prevent a late season slump. Stay tuned to this blog for more Spring Training in the fundamentals of Salesforce administration and development!

App Development Best Practices Whitepaper

Previous Article
Spring Training Episode 3: Salesforce Reports and Dashboards
Spring Training Episode 3: Salesforce Reports and Dashboards

One of the best things about Salesforce is the ease with which data in the system can be represented in use...

Next Article
Salesforce Admin Hack Series: User Object
Salesforce Admin Hack Series: User Object

As Admins, we all use the User object right? So why not “hack” it up??  Michael Farrington and I return wit...