Tricks all Salesforce Admins Need part 7 of 7 – When to Implement a Validation Rule #ForceFriday

Validation Rules are great! They force data quality, ensure users follow a process, and are part of a mature system. But, sometimes it can be difficult to determine when and where to implement a validation rule. Below I describe a framework (I know, my favorite) that will help guide what should be implemented as a Validation Rule.

Without further ado, I give you a Validation Rule decision framework.


When deciding if a Validation Rule is needed or not ask yourself three questions.

Should your field be required?

Is the field part of a step process?

Do you just need a warning message?


~ If a field needs to be require every time a record is edited then a Validation Rule should not be used. A Field Level requirement should be implemented.

~ If a field needs to be required sometimes (i.e. specific criteria) then a Validation Rule should be used.

~ A step process is any business process that has field dependent requirements. Validation Rules can be implemented to validate each step in the process, ensuring no steps are skipped.

~ Warning messages or “Soft Errors” aren’t supported by Salesforce just yet but please continue to vote for this idea – Validation Rules prevent the saving of a record whereas the warning message would allow a record save but display a warning based on your criteria. However, there are other options outside of Validation Rules which you can explore.

  • Use a Formula to display a dynamic message based on your warning criteria
  • Use a Visualforce page to display warnings
  • Use the Process Builder to push a Chatter Post (based on criteria) to users indicating the warning


** Note: Some Standard Salesforce Fields can’t be made required at the Field Level (e.g. Address Fields). The work around is to use a validation rule. You can vote for this idea if you run into this issue –

Tricks all Salesforce Admins Need part 3 of 7 – Effective Embedded Analytics #ForceFriday

Also called Report Charts, Embedded Analytics gives Salesforce Administrators the ability to publish a filtered Dashboard component directly on the page layout so users can see key metrics for that record without navigating to a Dashboard. Embedding certain types of metrics are more effective than others and in today’s post I am going to focus less on the How To of implementing Embedded Analytics and much more on the What To.

If you are interested in learning how to implement Embedded Analytics Salesforce Help and Training provides an excellent guide:

What we need here is a Framework! I present to you: The Embedded Analytic Decision Diagram!

Embedded Analytics Venn Diagram

Venn Diagram anyone?




At the intersection of Actionable, Measurable, and Relatable we find our ideal candidates for embedded analytics. I’ll explain each in due time. Using this framework can help you identify what is going to be most effective to display. There’s a limit of 2 report charts per page so you want to make sure that you are displaying the most effective information you can with the limited space you have.


Let’s get this one out of the way quickly. If you can’t report on it in Salesforce then you can’t embedded it as a Dashboard component on the page layout. Your metric needs to be something that can be measured. This is the concern of the Salesforce Admin because there may be relational database changes needed in order to create the reporting needed.

Let’s take the example of an Apartment Complex. Apartments have Residences (Accounts or Person Accounts) and they consume Resources (Apartments, Garages, Parking Spaces, Electricity, Water, etc.). A measurable metric might be water consumption by Resident displayed over several months. In order to report on this within Salesforce water consumption records must be related to the Resident through a Lookup or Master-Detail relationship.


Take stock in your audience of the the component you are considering. Can Jane Sales Rep understand the data presented in this component? Can Joe Support Agent use this data to better serve the customer? Does the component .ell a story?

These are some simple questions to ask but they each dive into what the data behind the component is trying to tell you. I like to refer to this as the story behind the data. If you have data for data’s sake then its not useful. The narrative the data tells you is much more useful. What’s even more useful is if that narrative matters to the person viewing it.

Opportunities in Pipeline might not be directly impactful to a Support Agents duties but certainly might be useful for a Sales Rep. However, Number of Escalated Cases in the last 3 month may tell a much better narrative to both the Support Agent and the Sales Rep, something they both can relate to. Understanding the narrative behind your data will help to determine a relatable component.


Much like data that doesn’t tell a story, if your users can’t do anything with it the data you give them the data is useless. When considering embedding analytics into a page layout we need to consider what actions our users might be able to take based on the data they are presented.

Let’s take our Water Consumption report example from above. Water Consumption is related to the Resident and measuring it over several months certainly can tell a story. But who cares if your users can’t do anything with it. Let’s say we are displaying this data in a component to a leasing agent who is working with a resident to sign a new lease. The leasing agent sees the component and notices a spike in water consumption in the last three months. She discusses quickly with the resident the possible reasons for this and finds out that the kitchen faucet has been leaking. The leasing agent can then easily dispatch maintenance to fix the issue, improving customer loyalty and satisfaction.

When implementing a component on the page layout, embedded with field level data, we need to consider what actions might be taken from a quick analysis of the data itself. If the data won’t result in your users taking action then its not going to be effective.

How I approach troubleshooting any Salesforce issue – A Framework

This is my first post. I’ve mostly been against blogging in the past for one reason or another. I’m like Han and his trusty blaster… Who needs those new fancy lightsabers? However, I’ve come to see that they can be a good outlet that forces me to get some of my thoughts/experiences out there and to keep me accountable for making sure I completely develop those thoughts. Without further ado…


I wanted to approach this blog as more of a framework approach to Salesforce. I imagine I will certainly post about specific issues, situations, best practices, etc. but proving frameworks helps everyone be more efficient. As my first post, I wanted to provide a framework on how I troubleshoot any issue within Salesforce. This helps me to collect my thoughts and be efficient with the time I have to troubleshoot the issue.

Here’s a fancy Graph:

Tell Me/Show Me

We all have customers. Customers can be internal customers or they can be external customers but in the end we are all customers of one sort or another. The framework I use to troubleshoot any issue is to have the customers Tell Me or better yet, Show me the issue. There is really no replacement for getting eyes-on an issue and having the customer share with you the specific issue, how they are getting to it (i.e. steps to reproduce), and why they are frustrated. This helps you identify the issue but also gives the customer a sense that they are being taken care of. This initial step in the framework could be considered information gathering but it provides much more to than just details. This step gives the customer confidence in you directly. You now know what the customer knows.

If your organizations support process does not include this step you should consider adding it. You will see support metrics improve. Issues that go into a generic “box” that has no face to it doesn’t inspire confidence on the customer side.

What Changed

The vast majority of issues fall into a few buckets. The last bucket in this list is self explanatory and I won’t spend much time on it.

Something Changed – Change it back
Something Needs to Change – Change It
Nothing is Actually Wrong – Do Nothing

In this step we determine which bucket our issue falls into. Based on the information gathering that you did in the previous step you identify what may have changed to cause the error/issue. A simple example provides a good basis for what this step might look like:

Customer Issue: I can’t see field XXX

What Potentially Changed:

  • Field Level Security
  • Page Layouts
  • Field

Now that you identified what potentially has changed you further identify what might need to potentially change to resolve the issue. For our example, they are the same thing:

What Potentially might need to be changed:

  • Field Level Security
  • Page Layouts
  • Field


What’s Related

Salesforce is full of relationships and that’s a good thing. Relational databases are useful as are relational features. Knowing and identifying the relationships that are associated to the features that you identified in the previous step will help you to formulate the resolution… which is coming… I promise… In the next step.

In our example:

  • Field Level Security – Related to the Field
  • Page Layouts – Relate to the Object and the Field
  • Field – Relate to the Object, Field, and Page Layout

Mapping out the relationships helps to identify where we look first. The more related the feature is the more value you place on it and therefore look there first for a potential issue. In our example, we would look on the object record for the field that the customer can’t see to ensure that its still there. We would then work our way down the list of related features that we identified.

What’s Missing

If something isn’t working as intended then something is missing; either its missing because something changed or something needs to change. Notice that I didn’t mention that a configuration change is always needed here. A process change might be necessary as well. The previous step helps you to systematically identify what is missing in a setup configuration. In my experience, most issues within Salesforce are resolved by a configuration change of some sort. Knowing systematically what to look at first and what to change helps to efficiently resolve the issue. Once you do find what’s missing, make a change and verify the issue is resolved with the customer.

But what if you don’t find anything in the configuration that needs to be changed? Answer – Something is wrong with your Process! More detail on this in a later post but suffice to say, establishing process is key to avoiding errors and ensuring a happy, efficient workforce.