Validation Example Rules

Validation Rules are useful to check data quality and force users to add information if required (instead of making a field required) when it needs to be there e.g. when the status becomes active, make sure the listing price is present (things that are perhaps mandatory by the portal (not to be rejected) or others that you simply want to never forget (data quality)). You likely will find some default rules on the listing object but might need to adjust or amend them to you needs. You can also deactivate rules if they are not valid for your usage.

Note: In this article there are some validation rule examples you can, but you need to think about which API field names you are using and adjust them accordingly when creating your own rules.

Example Validation Rules for: 

General Example Rules

If you want to prevent changes made once a certain picklist value has been chosen (then only admins are allowed to change that specific picklist value). In the following case, this is done with a listing status preventing anyone from changing it once it is "Published", but could easily be applied to other objects, too:

ISPICKVAL(pba__Status__c, "Published"),
OR (
ISCHANGED ( pba__Status__c )
$Profile.Name <> "PB Administrator",
$Profile.Name <> "PB Office Admin"


In the linked article below Salesforce explains how to disallow making changes to a "closed" closing (Salesforce calls this "Opportunity", simply replace that with "Closing" when reading it):


Picklist validation with a Date field to be mandatory

Situation: You want to make sure to capture the closing date the latest when the closing status is changed to "Closed".
Solution: To do that, the user agent must populate the closing date if this validation rule is in place:

ISPICKVAL(Closing_Status__c, 'Closed'),


Picklist Validation with another Picklist field to be mandatory

Situation: when a contact becomes an active contact, you want to be sure that the contact type has been set.
Solution: The following validation rule will ask the user to select at least one contact type from the contact type multipicklist before he can change the contact stage to "active":

ISPICKVAL(Stage__c , 'Active'), 



Note: Picklists and Multipicklists can be tricky to use in formulas and you might need read Salesforce help (see below) or search how others did it.

You can use validation rules on other records as well, Salesforce has some great ideas here:

Listing / Portal Example Rules

Portal Mandatory Fields Validation

To make sure that listings can only be published on a Portal e.g. to Rightmove, so the status changed to "active"=is ready to be published, you will need to create one or more validation rules that check that at least all mandatory fields have been populated. You can use something like this:

ISBLANK(pba__Broker_s_Listing_ ID__c),
ISPICKVAL(pba__PropertyType__ c,""),
ISBLANK( pba__ListingPrice_pb__c ), 
ISBLANK( Summary__c ), 
ISBLANK( pba__Bedrooms_pb__c ), 
ISBLANK( pba__Description_pb__c ), 
ISBLANK( pba__City_pb__c ), 
ISBLANK( pba__PostalCode_pb__c ), 
TEXT(pba__Status__c) = "Active", 
TEXT(pba__Status__c) = "Any Other Custom Status That Should Be Allowed To Go Online", 
TEXT(pba__Status__c) = "Under Offer" 

which will check for one of the fields to be empty and that one of the listed statuses is present (so it can be more than just "active").
A validation rule will only have one error message, so with this example, the user will have to look for the field that is empty. You can also create a rule per field, then the error message can appear right next to the field.

Energy Certificate Information

As legal requirement you often have to ensure that you provided energy certificate information when publishing a listing. To do this, you can either check each field or a set of 2 fields (like the above) to have content, or you build a rule that might be a bit more complex but captures the situation best.
So, you could check when a listing is "active" and the energy fields are not "Patent Pending" or "not applicable" that the values have been added. That means the picklist may not be empty and when a letter (energy rating) is chosen, you must add the corresponding value:

ISPICKVAL( pba_espfields__Energy__c, "A"),
ISPICKVAL( pba_espfields__Energy__c, "B"),
ISPICKVAL( pba_espfields__Energy__c, "C"),
ISPICKVAL( pba_espfields__Energy__c, "D"),
ISPICKVAL( pba_espfields__Energy__c, "E"),
ISPICKVAL( pba_espfields__Energy__c, "F"),
ISPICKVAL( pba_espfields__Energy__c, "G"),
ISPICKVAL( pba_espfields__Energy__c,""),
ISPICKVAL( EnvironmentImpactRating__c,""),
ISPICKVAL( EnvironmentImpactRating__c, "A"),
ISPICKVAL( EnvironmentImpactRating__c, "B"),
ISPICKVAL( EnvironmentImpactRating__c, "C"),
ISPICKVAL( EnvironmentImpactRating__c, "D"),
ISPICKVAL( EnvironmentImpactRating__c, "E"),
ISPICKVAL( EnvironmentImpactRating__c, "F"),
ISPICKVAL( EnvironmentImpactRating__c, "G")),
ISBLANK (pba_espfields__Energy_Performance__c),
ISBLANK (EnvironmentImpactValue__c)),
ISPICKVAL(pba__Status__c, "Active")



Field Length Limitation Validation

And of course, you can add more fields or criteria to enhance listing quality, e.g. limit the amount of characters allowed in the address field by using:

LEN(Addressfieldname__c) > 60

-> This could be required if a portal rejects a listing because a field's content is too long or you can use it to force a user to keep it brief.


Postal / ZIP Code Validation Rule Examples


1. A portal requirement (e.g. in the UK) often is that Postal Code must be in upper case . You can remind the user with this rule:


2. Sometimes only certain postal code formats are permitted. To prevent a user from adding something else, you can check what was entered with regular expressions. In this example, this is what Idealista will expect to see: a format like AD123 or 12345 or 1234-123, so 


Obviously, the fields in the formulas need to contain your API field names.

Images/Media Example Rules

You can also use validation rules to check whether images have been added or go even a step beyond and check whether images (at least one) has been added to be published e.g. to the Portal Feed(s).

In order to achieve this, you need to understand first, that the images (and media) you upload to "Media Manager" are part of the "PropertyMedia" object which itself is a child to the "Property" object.

Knowing this, you can use so called "Roll-up Summary" fields to count the amount of records related to the Property. And lastly, you can have the listing check whether there is a positive count on the related Property for images.

These are the 2 steps for this basic rule checking if there is any media present:
  1. Create a new field of type "Roll-Up Summary" on the "Property" object called "PropertyMediaCount" counting "PropertyMedia". After creating it, it should look somewhat like this:

  2. Then switch to the "Listing" object in Object Manager and add this validation rule (note: if you used a different field name for the counting field on Property, please adjust accordingly):
    OR(TEXT(pba__Status__c) = "Active"),
    OR(pba__Property__r.PropertyMediaCount__c = 0))

    This will ensure that there must be at least one image (count greater than 0) when the listing's status becomes "Active". Obviously you can add your own "active" statuses as explained in other rules in this article.

Recommended Addition: You can even go a step further and have different Roll-Up Summary fields on the "Property" object counting different cases: when creating a roll-up summary field, you can also add criteria to what the field should count.

If you choose e.g. that "Portal Feed equals true", then it will only count the amount of images that have been added specifically to be published to portals. If the validation rule then checks for "greater than 0" on that field, it will basically check, if not only images are present, but also ensure that at least one has been added to be published to portals:

Of course you can do this with "website" or "exposé" as well and you could go yet a step beyond and check whether the mime type is an image (and not a document or pdf) and vice versa.  So there are multiple combinations you could use this with criteria on the field.

Contact Example Rules

This article also has some useful examples:  https://developer. us.usefulValidationRules.met…

Validation rules can also be great, to make sure a contact is qualified, e.g. has a phone or an email ->
Contact Communication Channels Quality Check e.g. as Active Lead Qualifier
So the contact must have at least one communication channel:

If you only want it to be enforced upon creation:

If you want it enforced even when its being edited:

If you want to enforce it when the stage = active:

ISPICKVAL(Stage__c, "Active"))

or using the managed stage field and checking for at least one of three values mobile, phone or email to be there:

ISBLANK( MobilePhone),
ISPICKVAL( pba__Stage_pb__c , "Contacted Lead"))
Even more useful validation rule ideas can be found here: us/sfdc/pdf/salesforce_…

Closing Example Rules

Situation: You don't want to allow more than one closing being created for a listing.
Solution: We have some "system" checkbox fields on the listing object that should be ticked automatically when you start a closing (check "Offer Automation" and "Closing Automation" in Process Builder). When these boxes are checked, you can have future closings check on their related listing, if these checkboxes have already been checked and by that disallow the creation. Also, you will need the "IsNew()" check in the validation, to only check this for new closings, not the existing one or you will not be able to edit your single closing either after creation. This kind of validation rule is a so-called cross-object validation (see more on Salesforce Help):


NOT(pba__Listing__r.pba__SystemHasAcceptedOffer__c = FALSE), 
NOT(pba__Listing__r.pba__SystemHasExclusiveOffer__c = FALSE), 
NOT( ISPICKVAL(Closing_Status__c, "Canceled" )))


Note: you will want to ensure that canceling the closing also unchecks the tickboxes. Update your "Closing Automation" Process Builder rule accordingly.


Powered by Zendesk