function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
marcusaureliusmarcusaurelius 

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?

 

tx

AvromAvrom

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,

Avrom

 
marcusaureliusmarcusaurelius

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

 

- entering info A

 

and

 

- entering info B

 

A and B are in the same object

AvromAvrom

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,

Avrom
marcusaureliusmarcusaurelius

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

 

 
marcusaureliusmarcusaurelius

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

AvromAvrom

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.

 

Best,

Avrom
marcusaureliusmarcusaurelius

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..
AvromAvrom

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.

 
bob_buzzardbob_buzzard

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.