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:
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:
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: https://developer.salesforce.com/docs/atlas.en-us.usefulValidationRules.meta/usefulValidationRules/fields_useful_field_validation_formulas.htm
and in this PDF "EXAMPLES OF VALIDATION RULES" here https://resources.docs.salesforce.com/206/latest/en-us/sfdc/pdf/salesforce_useful_validation_formulas.pdf
Listing / Portal Example Rules
Portal Mandatory Fields Validation
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"
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
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( 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")),
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
Postal / ZIP Code Validation Rule Examples
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
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:
- 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:
- 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
Validation rules can also be great, to make sure a contact is qualified, e.g. has a phone or an email ->
If you want it enforced even when its being edited:
If you want to enforce it when the stage = active:
or using the managed stage field and checking for at least one of three values mobile, phone or email to be there:
ISPICKVAL( pba__Stage_pb__c , "Contacted Lead"))
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.