function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Page-specific validation rules

I'm looking for examples of how we can only have specific validation rules trigger on certain visual force pages.


We have created validation rules using the native SF functionality.  Now we are trying to create some kind of conditional statement that reads:


if you are saving from xx vf page, enforce these validation rules


looking for a trigger/extension - free solution!!


any ideas?




Hi marcusaurelius,


This is actually something I would not recommend doing. The main reason is that it's not secure--it's very easy to fake up which page you've submitted from, or even to write an HTTP request yourself. I'd suggest making the validation rule fire based on, say, the user's roles; you can make these roles line up with the pages available to the user. Role information, unlike page information, is secure and can't be faked.


Hope this helps,




Tx ..user roles probably won't work in this needs to be something akin to the page..something that can distinguish between


- entering info A




- entering info B


A and B are in the same object


I think I might need to know a little more about the use case.


Is the issue that, say, when you're entering info A, fields in info B might be null (because that happens on a separate page)? In that case, just change your validation rules so that they don't fire if relevant attributes are null. Is it that validation for info B shouldn't kick in until A has been submitted? Then set a field value as part of the A info submission process.


Basically, "what page the user is on" must be acting as a proxy for *something*--stage in a business process, who the user is, the particular type of this record, etc--that should be encapsulated as data. Validation rules attach to your *data*--and your data doesn't change its validity just because you're seeing it through a separate UI (although it might change its validity based on a data state the current UI is a proxy for).


Hope this helps,



tx Avrom - we have an object with 2 use cases


1. user enters info on vf page A >> saves


2. user enters info on vf page B >> saves


and we have validation rules...the problem is validation rules intended for use case 2 are firing on use case 1




i know this can be solved by having our end users update a field on the vf page and set validation based on that page..


what we are trying to avoid is having the user do this..i.e having the system know what page the user is on and set validation accordingly


Sorry, I still don't quite understand.


Why do the validation rules "intended" for use case B fail when fired on use case A? Is it that various fields might still be null (because nobody has yet completed use case B for the object)? If so, *that's* what you should add to your validation rule. The data itself doesn't become valid or invalid depending on the user's current use case; data validity is something that should change only when the data changes.





thats exactly it!  there are about 15 fields on the vf page b that have validation applied to them


these fields are null while saving on use case A .... if i was doing this natively, i would use record type ids to base the validation on..


Then for each of those fields, modify the rule so that it automatically succeeds if the field is null.


Or, if you don't want to let someone on page B set exactly one of the field valies, modify the rule so that it automatically succeeds only if *all* the "B" fields are null.



I've used the following mechanism when handling this in the past:


Add a stage field to the object that is being edited that mirrors the page flow, for example a picklist with values of 'stage_a', 'stage_b' etc with a  default value of 'stage_a'.


Alter the validation rules to include the stage in the condition.


Use extension controllers for each page that set the stage accordingly before calling the standard controller save, e.g. for page B the extension controller would set the stage to 'stage_b'.  Or if you are using custom controllers for each page, simply set the stage prior to attempting the save to the database.